Probably because what AAA game developers actually use is strictly Visual Studio, not C++.

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.

Ditto. Also your debugger of choice (Windows again). I can debug C#/C++ in one app (or other .NET language). It's bit of pain for anything else (granted, Rust, I'm told should be good).

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).

There are some AAA game engine and graphics developers actively using Rust in their main codebase like RAD and Embark, and many are Rust curious and using Rust for side projects or tools. It's true that it will be a while before wide Rust adoption happens in the game industry (if ever) and C++ will stay around for a while. As for tech in games moving slowly... there is some truth to that but some things also move much faster than web dev due to new consoles cycles with new hardware capabilities. It will take a LONG time for a SV startup to fully embrace WebGPU even when browser support is decent, on the other hand every AAA game engine has HW raytracing support

Chucklefish, the developer of Starbound, uses Rust too. The lead dev on the project gave a great presentation [1] at RustConf.

[1] https://youtu.be/aKLntZcp27M

I'm aware of Chucklefish's usage of Rust, but they aren't a good AAA example even if they've shipped some of the most successful indie titles of all time. Also, as mentioned in a sibling comment they have abandoned Rust because the lead programmer that was driving it moved on.

(They did but have since stopped.)

Do you have any articles or any info on why they decided to stop using Rust? I remember seeing things about them using Rust but never saw anything about them not using it and I'm curious.

They made a few offhand comments on Reddit, but that's it.

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.

> Let me tell you that most C++ game dev never heard of 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.

If you count Unreal engine game devs then I could see it being true. Many devs script with blueprints or work on art or sound or level design etc. Not every Unreal dev codes with C++ daily.

That's a great argument on why it is not present but the future instead.

These are not the only 2 options

And also a great opportunity!

"Future" doesn't have to mean "this year"

If you openly admit in a public internet forum that you use C++, you WILL be reminded that Rust exists and it vastly superior to your choice of tool. I find your statement very questionable and don't personally know any game developer (though I know a good number) that hasn't heard of Rust. So I would like to know if you actually know this from experience or are just guessing.

C++ developers who never heard of Rust sounds rather strange to me, like they are stranded on some isolated island.

They have work to do, and tooling to do it with.

Show them Rust, and they will say "what can it do that my tooling doesn't?", and then you must be silent.

It means they aren't curious about progress. Not someone you want to hire, unless those who run projects don't care about anything either. And sure, you can explain to them what better tools can offer. That was the point of the linked post. And if they don't want to hear the answer, then again someone probably hired wrong people there.

Game development shops are notoriously cheap. They have to hire people willing to work for peanuts. Like the circus, they take who they can get, from among people who need to be a part of the magic.

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.

Also: you assume you are the arbiter of progress. Not everybody agrees with your assessment.

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.

We are long past disputes about progress in this case. So it's simply not caring about it for those who don't see beyond what they are using.

The issue of intrinsic merit is nowhere near as settled as you imagine, even leaving aside time wasted by Rust's extremely slow compiler.

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.

> and according to the Rust core language developers will not.

Which feature are you talking about here?

Numerous features, with more arriving every third year. Operator overloading, exceptions, partial specialization, template function overloading, overridden move constructors, concepts...

Yes, there are many features that C++ has that Rust doesn't have, but "the devs say there never will be" is a different story. For example:

* 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.