That sounds like a completely valid reason to abandon C++ over Rust.
I mean, what self-respecting programmer that keeps up to date with the trends would use a such a dangerous language that makes code blow up in their face?
That is so '80s.
Well, I am joking, of course, but that comment is hard to take seriously.
Once upon a time we had reports from our users that our software had deleted all of the files it could on their C:\ drive. Investigating, we found the code that caused it, something to the effect of:
string rootDirectoryToDelete;
// Set it reasonably:
rootDirectoryToDelete = tempDirectoryWeMadeEarlier;
Want to guess what happened? We had a mix of Emacs and Microsoft Visual Studio 6 developers, and somehow we ended up with a mix of carriage return / line feed in that source file. Both Emacs and the MSVS6 IDE showed those as three separate lines... but the MSVS6 compiler thought that the comment... had no terminator. So it took the assignment on the next line as just being part of the comment.
You bet your ass I worry about code blowing up in my face. I write unit tests to try to protect myself.
I can't tell you how many times whatever the "undefined behavior" was what the code depended on, and fixing it required some severe re-working.
I also can't tell you how often someone thought "const" meant "completely immutable," and then they went on to accidentally modify what the const pointer was pointing at.
Or how often I've had to fix someone else's race condition. Or how often a driver crash has clobbered me.
I came across functionally like this in our code:
int i = 2;
int b = 3;
printf("i = %d, b = %d\n", (i, b));
Want to guess what that does? (i, b) evaluates i, and then ignores it, and returns b. So it basically prints "i = 3, b = [core dump.]" The MSVS6 compiler gave a nice juicy warning on that line that everyone ignored. Yes, using the MSVS6 compiler was dumb, and ignoring the warnings was dumb, but guess what? I'm not in charge of how dumb my co-workers are, or how strict everyone's deadlines are, and bugs like this are actually kind of hard to find in a real code base with tons of problems going on.
I'll take some more predictable behavior, if someone's offering it; yes, please.
Conversely, the rust spec defines... nothing. Rust is specified as "whatever rustc does." That means the compiler is free to be arbitrary on this sort of thing. When there is a spec and there are competing implementations, there will be behavior divergence, and that will create these kinds of issues. Not having a spec can be a good thing.
I'd love it if you could convince my old board of directors of that. But their first step would probably be to fire everyone who had survived the nightmare, because they "didn't already address it."
-Dwarnings -Funsafe-code
-Wall -Wextra -pedantic -Werror -O2 -march=(arch-of-computer) -pipe> use a such a dangerous language that makes code blow up in their face?
There have simply been too many CVEs relating to memory safety in C and C++ software. It's not the 80s any more and we can't afford that.
If you aren't connecting to the network or running in any sort of privileged mode, the space of attacks that you need to care about is pretty limited.
Ironically, the answer to a lot of unsafe input in Rust is to crash (if your error handling logic didn't catch it), which is something that you likely care about a lot. Most players care a lot less about corruption of the internal state of your video game than they do about crashes.
But yes, having worked in service games for over a decade now, clients are treated as untrusted agents regardless. CVEs that result in control over local execution are mostly not interesting. At least for the purpose of maintaining the game; platform holders _do_ care, mostly on fears of piracy.
Galoob didn't cause revenue issues with Game Genie in the 90's. And revenue is the thing what matters.
EDIT: One fun fact here is that AMD never did the unsafe performance optimizations that Intel had to remove from their silicon. Spectre and Meltdown mitigations were instrumental in closing the gap between Intel and AMD.
Rust is a good language and tracking memory access and ownership is something that's not always easy to do in C++, even with smart pointers.
For some projects, like browsers, that's a big deal, for others, like games, not so much.
But, it's not like you can't do dumb things in Rust. You can explode your code in any language you desire. Your skill is the only limit.
Cheating in games is a big problem, and lots of money is spent addressing it, not to mention techniques which are barely distinct from spyware which cause performance reductions on the side.
A lot of that cheating relies on bog standard memory bugs which game devs don't care about, apparently.
Some of us have spent decades working as sysadmins, getting woken up in the middle of the night to deal with whatever the latest CVE is... Do kids these days even know about codered, heartbleed, etc?
Things figuratively blowing up in your face are a concern even when not working on batteries.