Right now in the real world of AAA games it is nowhere, it's not even a consideration so calling it "Rust Is the Future of Game Development" right ...
For those who don't work in games, the tech there move very slowly, it's not your typical SV "let's use the latest fun and cutting edge tech".
Whatever is first class for GUI users on Windows in China and Ukraine is going to impact AAA game development far more than any non-GUI technology.
It's not really about tooling. I'm not saying tools. Just Visual Studio. Visual Studio decides what will appear.
Then you have the build process, vendorizing your packages (so you don't fetch them off internet), etc. Right now .sln files and MSBuild rule there (like it or not).
They decided that having a unified tech stack for the games themselves was worth more than Rust's advantages. Basically, they decided to re-build Witchbrook on top of Wargroove's engine.
That being said, I guess I should have put an asterisk on there; they aren't using Rust in game anymore, but they are still (apparently, last we heard) using Rust for server-side components. Wargroove's servers are implemented in Rust.
Why would you say that? I have no reason to believe it. C++ and Rust discussions frequently overlap so it's unlikely anyone who uses C++ hasn't heard of it. Game developers, in particular, are exposed to a larger segment of programming languages simply out of necessity. Searching for solutions or functionality will usually lead to esoteric options and the ever-present gamedev talks about how language X solves a portion of your gamedev woes.
Show them Rust, and they will say "what can it do that my tooling doesn't?", and then you must be silent.
Meanwhile, game developers, as a rule, are interested in (surprise!) game development, not languages. What Rust brings to the table, few game developers are looking for. But Rust builds are notoriously glacial, where game developers are wedded to the edit-build-test cycle.
So, gaming will be one of the last places for Rust to thrive. That doesn't mean no games will be in Rust. Rust coders will compete for jobs using it, rather than game shops competing for Rust coders.
For example: spending an extra hour or three each day, waiting for the compiler, might not seem like progress to everybody. Their assessment is as valid as yours.
Furthermore: you assume that people who hire must also agree with you. But, some people who hire want coders coding more and waiting for builds less. That is a legitimate desire.
The fact remains, and will remain, that C++ can encapsulate in libraries semantics that Rust cannot, and according to the Rust core language developers will not. As a direct consequence, it is possible to program at a higher level in C++ than in Rust. This gap will get larger as more libraries are written that exercise the difference, and as C++ adopts new features that expand the difference.
Within the HN echo chamber, the apparent situation is muddier because technical merits carry little weight vs. trendiness and surface sheen.
How likely game programmers are to use the greater capabilities is neither here nor there; they probably see more effect from the extremely slow compiler.
Which feature are you talking about here?
* Operator overloading: Rust already does this
* Exceptions: this is true, Rust will not do this.
* Partial specialization: is in nightly, will be made stable
* Template function overloading: not in Rust, nobody has said "never" though it is controversial
* overridden move constructors: this is true, it won't happen
* concepts: traits are already concepts and exist today.
The situation is significantly different than you've presented. We do have several features that we need to catch up to C++ in areas, but the big ones are on the way. It's more minor or stylistic, rather than capabilities, that are maybe not gonna be a thing.