I would say that the key defining characteristics of Rust for gamedev are that it’s strongly and statically typed, with a focus on highly optimized AOT compilation and low-level control:
- It’s good because it gives structure to your program and makes it easy to understand, which is more and more important as your game code becomes complex, all the while giving your compiler’s optimizer plenty of valuable information. It also catches a lot more errors at compile time, which is that much less time spent on debugging.
- It’s bad because you spend a lot of time juggling with the type system and waiting for long compile times, which could have been better spent quickly experimenting around with fun gameplay ideas. And dynamic constructs like trait objects get clunky because you can’t just put everything on the heap, duck-type all the things, and stop caring.
For a simple game (say, < 10 kLOC) where performance doesn’t matter, Python + PyGame might be a better option, due to the joy of the fast iteration cycle. You’ll get half of your lines of code wrong the first time due to the dynamic and overly permissive type system, but that’s okay, you can just continuously run the thing, write lots of tests, and fix what breaks, even in the REPL while the game is running if you like. The fun is worth it.
For more complex and ambitious game projects, or if performance starts to become an issue, I would go for a strongly typed language (not necessarily an AOT-compiled one like Rust or C++, fast JIT-compiled bytecode as used by Java or C# is quite capable already) just because all the static analysis and the mental structure provided by the stronger type system becomes invaluable when you need to manage a large software project.