Fellow C and Rust programmers, how do you live without classes?

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.

When you call player.move() are you mutating the state of player or are you really just logically attaching the move() function to the player object in order to keep your code... Logical?

player could actually be an interface to some object in an external database and move() could be changing a value in that database. Or player could just be a convenient name and place for a collection of "player"-related functions or stranger (yet weirdly common): A workaround for implementing certain programming patterns (Java and C#, I'm looking at you haha).

In Rust, attaching a function or property is something you do to structs or enums. It carries a very specific meaning that's much more precise and IMHO more in line with the original ideals of OOP (what they were trying to accomplish) and I think the way it's implemented (with traits) makes it far more flexible.

You can define a trait that requires a bunch of types/functions and then any implementation (impl) of a struct or enum that includes them can be said to support that trait. This allows you to write type-safe code that will work in zillions more situations and across many different architectures than you could with traditional OOP languages like C++ or Java.

It's the reason why embedded rust is kind of taking the world by storm right now... You really can "write once, run everywhere" thanks to careful forethought from the Rust developers and embedded-hal.

The only thing that makes rust different from cpp is the lack of inheritance. We have classes, they are called structs. And Interfaces, they are called traits.

But instead of inheritance if you want shared behavior between two structs you need to have both of them implement the same trait. So instead of

        fn pet(aimal: Animal)


  

You'd have

        fn pet(animal: impl Petable)   // polymorphism via monomorphization


  

Or

        fn pet(animal: &dyn Petable)  //polymorphism via dynamic dispatch


  

Instead of writing an animal super class you define a Petable trait:

        trait Petable{
        fn pet(){}
    }


  

We even have operator overload, because you can simply implement the f32::Add (or whatever) trait for your structs.

Ever since I learned Clojure, I’ve ridden the functional programming train. Now I write Elixir for my day job and even though I still have a soft spot for Java, the first language I wrote professionally, I think OOP in general is a flawed paradigm that makes bad software. But I won’t rant about it, I know these things can be a matter of taste for a lot of people.

In a functional language like Elixir, each function belongs to a module, which is just a namespace that lives in its own file. You just call a function with the module prefix, like

    
MyApp.Accounts.register_user(“me@example.com”)

  

There’s no inheritance, though there is polymorphism via something called Protocols. This makes it trivial to find the actual code you’re executing, which makes it so easy to debug stuff.

There are primitive data types, like integers, floats, and binary blobs (and strings are just binaries that are expected to be UTF-8), and then simple data structures like lists and maps. You can define structs, which are just maps with keys you define at compile-time.

I find that this leads to code that is way, WAY easier to design, write, read, and debug. I’m never stressing over trying to find the perfect abstraction for whatever I’m trying to write. I just write the function that does the thing I want. And you don’t need to remember a hundred different “design patterns,” either. There are a few simple patterns like map and reduce, and those are still just functions that transform data.

My dear friend - what if I told you that every call to Player.move should return an entirely new instance of a Player? One with an immutable position, and a helper function that takes a position delta - and constructs yet another Player!

What if I told you that all user interfaces are a function of application state; and all interactions apply a transformation that is then re-rendered? (We have gotten very good at only re-rendering the parts that change.)

Welcome to FP! There’s a whole world here for you to explore. You’ll be telling your friends about monoids and endofunctors before you know it :)

C programmer here. I can't code in Rust and although I do have some interest in learning it, C is still the best one to me. Probably not the best way to do it, but I'd do something like this (based on the code in your ss):

 c

    
typedef struct Player{
      float pos_x;
      float pos_y;
      float rotation;
} Player;

Player player_new(){
      Player player;
      player.pos_x = 0.0;
      player.pos_y = 0.0;
      player.rotation = 0.0;
      return player;
}

void player_move(Player *player, float x, float y){
      player->pos_x += x;
      player->pos_y += y;
      return;
}

void player_rotate(Player *player, float by){
      player->rotation += by;
      return;
}

int main(int argc, char *argv[]){
      Player player1 = player_new();
      player_move(&player1, 10.0, 10.0);
      player_rotate(&player1, 180.0);

      return 0;
}



  

I would probably move the struct Player and the functions player_new, player_move and player_rotate to another file (like player.c or sth), I'd create its respective header file with the definitions of each thing and with that I basically created a simple interface to create and handle players without needing OOP. English is not my native language, so I'm not really sure about what's the name of the programming paradigm used in C (which definitely is not OOP), but in my native language we call it "programación estructurada", which in English would be something like "structured programming".

Tbh I code in both non-OOP and OOP languages (most of the time C, JS and Python) and to me both paradigms are just fine. You can pretty much do anything in either, but each of them might work better for you on different situations and depending on your needs. I also use Vim btw.