Transprogrammer

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.

impl Player {
    fn move(&mut self, x: f64, y: f64) { ... }
}

player.move(10.0, 0.0);

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.

Somebody needs to RTFM ;) no seriously, Rust isn't something you can just jump into and guess what you're doing. Start with the official book and make sure you understand all of that.

IME the hardest part of Rust was learning the lingo to interpret compiler messages, and getting a solid grasp on references and borrowing. There is a lot more of course, like any language, but to me that was the steepest learning curve. I haven't used it in a few years tho, after losing all interest in programming.

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.

I don’t program in Rust, but IMO non-mutable by default is how it should’ve always been. It’s more reasonable to make values mutable out of necessity - not make them constants just because you can. Even in OOP I think you should avoid using variables when possible, as they commonly give rise to logical errors.

I think it’s harder to reason around programs that heavily use variables. It’s easy to tangle yourself into a mess of spaghetti code. You need to read back and forth to understand all the possible states the program can be in and ensure none of these states will break it. “Oh, you can’t call this method on line 50 because some other method call on line 40 changed some internal value, which isn’t corrected until line 60”.

Same code without variables is usually easier to read. There’s only one state to consider. You just read the code from top to bottom and that’s it. Once a value is set, then that’s final. No surprise states.

Variables also tend to make multithreading more difficult to reason about.

Your example with player movement is one example where variables are needed. You should keep using mutables here.

I think all programmers should learn to program in a more functional style. Even if you end up using OOP you can still make use of functional programming practices, like avoiding variables.

While at first, Rust's lack of inheritance threw me off, I've found that traits do plenty of heavy lifting in that department.

Edit: Also, you can make class-like accessors and functions with impl blocks. Is that what you mean?

I still use C for embedded device programming and it's really just about splitting code into separate files by what they do if an app ever gets too big.

If you really need something OOP'ish, you can use function pointers inside of a struct. You would be lacking the OOP syntax of C++, but it's fundamentally similar.

When you are counting bytes for firmware, it's helpful to have a language like C. In theory, it limits code complexity and is much easier to estimate what is going to be shat out of the compiler. Honestly, byte counting is super rare for me since there is just so much program space on devices these days. (If I did any work with ATTiny MCUs, I would probably coding in .ASM anyway...)

While I don't code in Rust (yet), I still think it makes perfect sense not to leverage classes. My limited experience in *lang languages taught me that simple functions are perfect for heavy parallelization. By restricting the number of pointers you are tossing around and using only immutable values, the surface area for failure is drastically reduced. (This is also awesome for memory safety as well.)

Just remember that all languages are tools and you should use the tools that fit the job. Efficiency should always be top of mind and not the nuances of a language. (I grew up learning how to conserve CPU ticks, so that should explain my point of view.)

I use helix as my editor. It's vim-like and great for rust right out of the box with no configuration. So much so that it replaced my 300+ line 20+ plugin neovim configuration with 1 line of toml (to set the theme). It's also written in rust :3

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 :)

I only use C when I very likely don't need classes, and if I then still need to, I can fake them more or less well with structs, functions and pointers to functions in structs.

Absolutely no problem. I've done decades of programming in C, and it's absolute fine. For a bigger project, you need discipline, yes, but there are bigger projects in C out there that prove that this can be done.

Actually, my error rate is way below that of my coworkers who do C++ and C#, despite that I'm working directly on the iron (i.e. there is no OS between me and the processor, no interprocess protection, or similar).