I haven’t used Rust yet but I’m a strong advocate for the SOLID principles so I tend to be pro having a more difficult time writing code more correctly.

I have mixed feelings about Rust for game development. The biggest problem is its “shared xor mutable” default. Games are all about mutable state.

This is true and it’s also true that most languages handle mutable state poorly which causes major issues with concurrently solved mainly by keeping all logic on a single thread.

You often want to have a mut ref to an entity and const access to the rest of the game state (which itself refers to the entity).

This statement admits it’s contradiction. A mutable access to a const global state isn’t a real thing, it’s a precarious false thing that many classic languages erroneously allow. The simple solution is to admit that the whole game state is mutable all the time and that concurrent access to it will always be unsafe.

There are solutions to this but unless you want to run multiple threads then I don’t see much reason to worry about it, otherwise it was going to be an issue no mater which concurrent language you wrote your game state in.

Mutable reference pointers have many of their own issues and I feel sorry for anyone who has to learn about reentrancy from Rust. Learning about alternatives to pointers is a good lesson to bring back to any language.

Languages like Java and JavaScript prove that there’s no actual reason that you can’t have that AND be memory-safe.

Borrow checking is more about race conditions than memory safety. JavaScript is single-threded so I’m not sure how much it compares to Rust. Rust gets its memory safety from its stricter handling of types.