To be clear before I respond, I believe there were some overzealous individuals that were concerned about unsafe usage in the project and did a very poor job of

To be clear before I respond, I believe there were some overzealous individuals that were concerned about unsafe usage in the project and did a very poor job of communicating with the maintainer. This follow up post drives at the heart of that: https://raphlinus.github.io/rust/2020/01/18/soundness-pledge.html https://raphlinus.github.io/rust/2020/01/18/soundness-pledge... Now to your question. Rust is a language that allows you to express correct programs in a number of contexts. Memory safety and concurrent modification free code being two chief ones. What people are constantly proving is that unsafe escape hatches for performance reasons are not as regularly required as similar C implementations would make you believe. In games and HFT, I would argue having correct programs is as important as any other area of development. That’s the gamble, that you no longer need to make the trade off of safety vs. correctness. But, for expediency of development I could understand why folks see this as a trade off that is required, but that’s really just about the maturity of the language ecosystem in those areas. Ideally any unsafe code will be contained inside a crate and never be exposed to users of that crate. The crate says “I’m giving you these safe APIs and if you use them, then your code will be safe”, it’s a contract. The point being, for games and HFT, there are many cases where you’re interacting with hardware to improve performance, the big question then becomes, can those hardware abstractions offer safe APIs such that any code built on top of them would be safe. I’d argue Rust proves that this is possible to do, and in answer to your ultimate question, that yes, even in these contexts, Rust would allow developers of those types of programs to build more correct software.