It's a modern language: no #includes, faster compilation (compared to template-heavy C++), nice macros, compile-time reflection (libraries like Serde are really nice), generally nicer stdlib than C++, decent package manager. And it's one of the only languages with RAII/destructors, which to me are one of the best things about C++.
>Also, I'd argue that memory safety/rce protection/etc is crucial in games, particularly ones that are online.
This applies to the server, but not to the graphical game client running on the user's machine, as the client is usually not accepting random inbound connections, instead it just connects to the server.
>This applies to the server, but not to the graphical game client running on the user's machine, as the client is usually not accepting random inbound connections, instead it just connects to the server.
There have been a few demonstrated RCEs in game clients (especially in P2P models which many modern games use).
You should profile/benchmark that with a couple thousand lines of code... C++ can be slow to compile (although it isn't always), but so can Rust.
I will add to your list that Rust generally has nicer error messages.
However from experience I can say that you can use Rust against the grain, which will result e.g. in constant fights with the borrowchecker, weird solutions to get around the typesystem and a ton of unsafe (=trustme) blocks.
Rust can do a lot for you, you just have to think a little more about a programs architecture and don't force paradigms like OOP onto it.
If you wrote a game engine in Rust, and open-sourced it, you'd probably get similar grief. Because that's what Rust is largely about. Anyways, certain high performance render applications (browsers, ahem), don't seem to suffer significant penalties.
Also, I'd argue that memory safety/rce protection/etc is crucial in games, particularly ones that are online. HFT running in a contained env? Less so, for sure.