I think you may be overestimating the pace of change. C++ is quite entrenched for industrial-strength game projects. The network effect is strong, the tooling is mature, and the projects are largely driven by C++ experts. Even if we see Rust 1.0 by the end of the year, it will take a lot of time for that kind of change to occur in the industry, if it ever does.
I think you're much more likely to see 51% of new game code written in C# for Unity. I think the median game budget is shrinking. More and more games are being made as small projects by small teams. Steam greenlight, kickstarter, humble bundle, and other avenues are enabling curation and funding of smaller games. Unity is far more suited for this kind of development than C++. If you look at smaller studios' job listings, a lot of them prefer experience with Unity. The trend is in full swing at this point.
I have no sources to site for the above information. Take it with a grain of salt.
In addition to your point, I'd like to stress that it is the game engines that are C++. Many engines provide a higher level interface for developers actually make games. You probably won't hook the game developers on Rust. If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun. Not to mention, you'll also be battling against the traction of their current codebase, which they'll probably hesitant to rewrite in a new language. From a business perspective, I don't think management in some of the larger companies would let that decision fly, either.
All good points but there is one strong argument in favor of Rust: memory safety. It seems to be the norm for games these days to CTD (crash to desktop) sooner or later. I find that unacceptable to the point that it makes me angry.
C++ makes it way too easy to corrupt random sections of memory.. which leads to random CTDs. Rust was designed from the ground up to prevent these dreadful bugs.
AAA games are overwhelmingly written by relatively inexperienced, overworked cowboy coders on a tight schedule who are expected to write optimized code. Expecting C++ code without memory corruption bugs in that situation is simply unrealistic.
As a customer I truly hope the industry adopts Rust or another language where memory corruption is impossible or only possible if you explicitly ask for it. I am so sick of CTDs.
If you want to pitch Rust to the engine guys, you're going to be battling against their toolchains that have been developed for decades and have some of the best static analysis tools under the sun.
I've never used static analysis tools for C++, but from what I've heard, the reason they need to be so advanced is because C++ is so difficult to analyse. Rust, on the other hand, with it's strong, static type system, may not even require extra static analysis tools to be used effectively.
This is a specific instance of a general argument that applies to all new languages: there is an existing infrastructure and people won't want to switch. Yet new languages are arriving at a pace faster than ever on the server side, despite massive investment in server stacks for existing languages.
If Rust succeeds as a language suitable for games and gains traction there (and that is of course an if), I think the truth will be in the middle: there will be a huge amount of code still written in C++, and that will continue to be maintained and work. But new code might be written in Rust. Rust is designed to integrate well with C and C++ code, so mixed projects are quite feasible: in fact, both rustc (because of LLVM) and Servo (because of SpiderMonkey) are such mixed projects.
Eventually something will indeed replace C++ for gaming. You can look at the emergence of all the new server side languages in two ways: either one will "come out on top" as something akin to what C/C++ is now or there will be much more specialization in what we now call "systems programming". If the future is the latter, engines might always be done in C/C++ simply because it gives them the ability to easily make bindings to the majority of languages (ie Rust). I believe this will be the middle ground of which you speak. It really would've been cooler if there was more incentive to build languages specially for games, especially since the domain has some interesting demands such as the close coordination with GPUs and memory allocation in general.
Didn't realize Rust had support for this. At the end of your recent example, it pretty much says doing so sacrifices the runtime entirely. I know Go doesn't support calling from C for reasons similar to this. Where does further development on this functionality sit on the priorities list for Rust?
Indeed, being able to forgo the runtime entirely is what makes it possible to rewrite the Rust runtime in Rust (as per the OP). Wouldn't be very useful to have a runtime that itself required a separate runtime. :)
As for "further development", what would you like to see? Currently the most prominent capabilities of the runtime are the lightweight task system and garbage collection. It might be theoretically possible to allow uses of the task system to gracefully degrade to using system threads, and likewise it might be possible for uses of the GC to degrade to refcounting (without cycle collection).
Being able to run runtime-less and still use the language is quite high on the priorities, and I believe moving GC to pluggable library types and cleaning up the standard library feed into that.
You don't actually have to sacrifice the runtime entirely anymore; since the runtime is written in Rust you can just start it manually if you want. Making this smoother is a priority. (Brian mentions this in the email, regarding #[start].)
I think you're much more likely to see 51% of new game code written in C# for Unity. I think the median game budget is shrinking. More and more games are being made as small projects by small teams. Steam greenlight, kickstarter, humble bundle, and other avenues are enabling curation and funding of smaller games. Unity is far more suited for this kind of development than C++. If you look at smaller studios' job listings, a lot of them prefer experience with Unity. The trend is in full swing at this point.
I have no sources to site for the above information. Take it with a grain of salt.