Late response and you might have already gotten an answer, but what you wrote is exactly the same as:

// Define our player struct 
struct Player {
     x: f32,
     y: f32,
     rotation: f32
}
// Define the methods available to the player struct 
impl Player {
     pub fn move(&mut self, x: f32, y: f32) {
          self.x += x;
          self.y += y;
     }

     pub fn rotate(&mut self, by: f32) {
           self.rotation += by;
     }
}

fn main() {
    let mut player = Player { x: 0.0, y: 0.0, rotation: 0.0 };
    player.move(10.0, 10.0);
    player.rotation(180.0);
}

The code example you wrote does not use anything that is exclusive to OOP languages as you are simply encapsulating values in a class (struct in the Rust case).

Unlike C++, the biggest difference you will find is that Rust does not have the same kind of inheritance. In Rust you can only inherit from traits (think interfaces in Java/C# or type classes if you have ever used Haskell), whereas in C++ and other OOP languages you can also inherit from other classes. In a lot of cases just using traits will suffice when you need inheritance. :)

So in conclusion, no global functions! You still have the same name spacing and scoping as you would in C++ etc!

Ps. I use VScode because it rocks with Rust, and while Rust is heavily inspired by functional programming languages, it is not a pure functional programming language (nor is C) but that is another can of worms.

If you want your code to be performant you need to think about how you lay out your data for your CPU to manipulate it. This case might work well for one player but what if you have 100, 10 000?

When you call player->move (assuming polymorphism), you’re doing three indirections: get the player data at the address of player, get the virtual function table of that player, get the address of the move function.

Each indirection is going to be a cache miss. A cache miss means your cpu is going to be waiting for the memory controller to provide the data. While the cpu can hide some of this latency with pipelining and speculative execution, there are two problems: the memory layout limits how much it can do and the memory fetch is still orders of magnitude slower than cpu instructions.

If you think that’s bad, it gets worse. You now have the address of the function and can now move your player. Your cpu does a few floating point operations on 3d or 4d vectors using SIMD instructions. Great! But did you know that those SIMD registers can be 512 bits wide? For a 4d vector, that’s 25% occupancy, meaning you could be running 4x as fast.

In games, especially for movement, you should be ditching object oriented design (arrays of structs) and use data oriented design (struct of arrays).

Don’t do

struct Player { float x, float y, float rotation, vec3 color, Sprite* head};
Player players[NUM];

Instead do

struct Players {
    Vec2 positions[NUM];
    float rotations[NUM];
    vec4 colors[NUM];
    Sprites heads[NUM];
};

You will have to write your code differently and rethink your abstractions but your CPU will thank you for it: Less indirections, operations will happen on data on the same cache lines, operations will be vectorizable by your compiler and even instruction cache will be optimized.

Edit 1: formatting

Edit 2: just saw you’re doing 2d instead of 3d. This means your occupancy is 12.5%. That operation could be 8 times as fast! Even faster without indirection and by optimizing cache data locality.

Your OO languages at their core just abstract patterns like using a *this pointer. OO is possible in any language once you understand how it works. You should just go back to C++ or whatever you’re comfortable with.