I'm predicting we won't hit JavaScript levels of diversity (the problem space is just that much harder in gaming then in web) where the diversity itself is a hindrance but given the metrics of interest in rust and it's ease of use compared to C++ it's just a matter of time.
If I'm wrong the only think I think I would be wrong about is when this inflection point occurs. Either we hit in the future or we just passed it.
(there are a couple of externally maintained bindings though)
PS: the most serious case against C++ for game development is probably the widening gap between "modern C++" and the kind of "sane C++" that's used in the game dev world (e.g. modern C++ is moving into a direction where most new features are entirely useless/pointless for game development). That was at least the main reason why I left C++ mostly behind and moved back to C (or realistically: a mix of mostly C and some C++ where needed to talk to libraries), and I keep a very close eye on Zig to eventually replace my use of C.
This is the easiest way we can automate bindings to other programming languages without having to use larger instrumentation like SWIG.
It's definitely not the industry standard recommendation I wrote about above, but internally we have other objectives that make it sensible. And we still get to use C++.
Betting on the status quo is definitely a pretty safe bet--and particularly over the timeframes of AA-AAA game development. And particularly for someone who is wanting to pick up a job in the industry tomorrow.
> for nearly 20 years, the physics library choices game developers have had has been a small handful
Another way of looking at that is that it means there's 20 years of pent-up interest from people who want a physics library that can benefit from the past 20 years of programming language & software development methodology improvements. :)
> If anything, in 5 years, you might have one new entrant that might develop a solution worth considering.
I think it's important not to discount the impact build tooling like cargo can have on adoption of Rust libraries and the potential for developing libraries in Rust but also exposing them via C and/or C++ bindings and gain adoption via that path as well.
And, due to a combination of "starting at the same time" & build tooling, the potential for cross-industry cooperation on development is greater too. (Questions about fields of endeavour aside, I note that Rapier physics-related projects are sponsored by both game companies & a mining-related company[0].)
(And with regard to scientific computing & Python--well how many people know or care whether the "fast" library they use with Python is implemented in Rust or C++ as long as it's stable & reliable?)
> You can absolutely have exponential growth and in major categories make zero impact to the industry.
True. From my limited perspective it all comes down to whether Rust can deliver on the promises it makes & whether it can make the cost of switching compelling enough for teams to move.
But there does seem to be quite a few people who are putting in a lot of work to try make that happen.
Of course, it's entirely possible the games industry decides against such a wholesale change in which case I guess anyone who learned Rust in the interim will just have to take a less underpaid job in a different industry. :)
[0] <https://dimforge.com/blog/2023/01/22/the-year-2022-in-dimfor...>
As an example, for nearly 20 years, the physics library choices game developers have had has been a small handful, and of those solutions, most use one of two major codebases.
No one is displacing that tomorrow, or next month, or even, I don't know, I'll be bold and guess 5 years from now. If anything, in 5 years, you might have one new entrant that might develop a solution worth considering.
You can absolutely have exponential growth and in major categories make zero impact to the industry.