I guess the real answer is, if you want to learn "the language that people will be using instead of C in ten years"... learn both of them.
Right, very difficult to move the inertia in any direction. The same is true about Java too.
But there are fewer reasons for any starting a new project to do it in C or C++.
Newer stuff replaces older stuff, Heck when C came along, there were languages with billion $ industry around them. C replaced them.
If anything, the current trend is moving more low level (rather than higher level, which these languages both are), as techniques like data oriented design becoming more mainstream.
> (rather than higher level, which these languages both are)
Rust should be (and is, modulo wrinkles, I mean there's no fundamental reason) as low level as it gets. What makes Rust too high-level for gamedev?However, modern AAA game dev is largely about customising and upgrading large existing game engines, which are all C++ based. Rust could be used for them, but isn't, and the extra features Rust brings are not compelling enough to rewrite huge amounts of working code and suffer (re)training costs.
This is a hole many new languages find themselves in. JetBrains have come up with a very clever solution for their Java/Scala competitor Kotlin: the language was carefully designed from the ground up with perfect Java interop in mind (Java/Kotlin call into each other seamlessly, the IDE can refactor across languages, Kotlin uses the same standard library etc). And quite amazingly, the IDE can automatically rewrite Java into Kotlin. This isn't a party trick, it works very well.
I think if Rust wants/wanted to be a serious competitor to or upgrade path from C++ it'd have needed to take at least some level of C++ interop into account from the start such that Rust and C++ could be intermixed freely. AFAIK though, the best you get is a typical C export/import layer which is too trivial to be compelling.
Of course, it's a lot harder than connecting with Java because of the way C++ stuff is defined using header files. But at least basic interop could have been done.
In that case some one just code "GoRust" language ^_^
Concurrent Pascal (1975) by Brinch Hansen http://brinch-hansen.net/papers/
...Concurrent Pascal used in Solo OS. It supported human review via readable syntax, type safety, safe ops on memory, and a concurrency system that caught race conditions at compile time. The runtime underlying the OS was about 4K with the OS itself concise enough to put in one PDF in source form. So, Hansen for the [1975] win in the GoRust competition?