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.