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

player.move(10.0, 0.0);

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.

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.

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.

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

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

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

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.

i don`t know i just never learned anything but C and asm. ps. i use doom emacs for its package manager over VIm or its flavors.

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

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.