Create templates to quickly answer FAQs or store snippets for re-use.
My rebuttal to the "C++ is from a bygone era" statement aside, I would say...
Nothing lasts forever.
We used to write games in various flavors of Assembly, in BASIC, COBOL, and (later) C. Now we develop many games in C++. Like I said in the other comment, I doubt C++ will ever be fully disestablished from the game industry, but it is by no means the only player in town. As other compiled languages prove themselves to be stable, performant, and reliable, they'll take their place in the mix.
C++ seems to hold its ground mainly in regards to game engine development, because it offers superb access to hardware, drivers, and memory, and the system overall. We need that sort of "bare metal" access to write performant game engines, and any language lacking the tools for twiddling memory directly has little chance of gaining ground here. Those that do offer those features in a cross-platform fashion automatically have to play catch up, since C++ has a 30+ year head start, and is continuously improved as a language and a platform (libraries and such).
But can it happen? You bet! I'd actually be surprised if we're having this conversation in 20 years. C++ won't always be ubiquitous, but I reckon it will always be present.
Besides that, look at the present situation with COBOL in the financial sector, and FORTRAN in the scientific sector: you will almost certainly need working proficiency to get far in either field, simply because all your stable, proven patterns and algorithms are in those languages. Thus, I'd also wager that you will "always" need a working knowledge of C++ in game development, even if the company you work for doesn't use it at all. Lacking it would be like being an archaeologist in Egypt with absolutely no knowledge of hieroglyphics.
If you only look at AA and AAA games yes, because you need raw performance, but every day hundred of games are launched using Unity3D and other game engines (on web, mobile and so on).
So ... it depends of your perspective.
I damn well hope not. C++ has many fundamental flaws about it. It is a language from a bygone era that only still exists because of inertia (libraries, available programmers etc.) and a lack of serious competition (any GC language has different goals). As you have mentioned, the later is changing and I expect Rust or some other language will replace C++ within 5 to 10 years.
"Bygone era" also brings with it precedence, stability, and more of a known quantity about it. It does have its "fundamental flaws", although...
The last two versions (C++14 and C++17) are miles improved from "old-school" C++, offering memory safety and dynamic typing features that rival the new kids in town.
All languages have fundamental flaws; most C++ developers are just comfortable working around the (ever diminishing) set of flaws in the language, as they're a well-known quantity. Newer languages have many flaws that remain as-of-yet undiscovered.
But then, as I've mentioned before, languages seldom die.
That certainly doens't mean C++ will remain unchallenged or ubiquitous, but I think it'll still make up a huge share of game development code, even ten years from now. Rust may well eventually displace C in newer projects, but it lacks a plethora of language features that C++ offers.
When they do, rest assured their adoption rates will increase.
All that actually has nothing to do with "inertia": it's simply that as developers mature, they learn to prioritize stability and known factors over shiny new toys. Major studios don't use C++ because they're a bunch of troglodytes; they use it because of its proven advantages. It'll be some time before the new languages have proven themselves to that extent. Senior developers, meanwhile, don't often pour extensive learning and library development time into those new languages for the same reason. Mayfly technologies abound, and we don't want to waste our time!
While your argument may be true for languages such as Java and Go, Rust is a different beast entirely. Where the former are essentially C or C++ with some opinionated changes based on whatever is fancy at the time, Rust is based around linear logic and is thereby backed by solid math. The von Neumann model of C has no such backing. This is what I mean when I say fundamentally flawed.
This was evident e.g. in the slowness with which concurrent programming was adopted, single-threaded performance having stayed a primary concern for gaming systems.
In contrast, initial predictions of MC system design spoke of 64 cores on a CPU by 2012. The lack of compatible software made this rapid scaling of core count unmarketable. This was shown e.g. in the AMD vs Intel debate, where Intel CPUs were better for gaming despite the fact that AMD's higher core count provided higher overall instruction throughput at a lower price.
I love working in C++ (starting from C++14 anyway) and will use it whenever I have a good excuse to do so, but I cannot deny a better, more elegant design when I see one.
I will however, fully disagree with the notion that more features makes a language better. More features means more complexity, which in itself is bad. Of course it might increase the expressive power of a language, but that is just one thing making up the total balance.
This, however, is a matter of personal preference.
Well I think D is positioned better for getting in the door. Being able to interface with c++ is a huge advantage.
If you want to seek a job in the AAA Game Industry, you should learn C++, no other languages beat it in term of performance, number of resources and hardware compatibility (for the gaming ecosystem, it should not be true for other fields).
This can apply to Unity/Unreal too (for other kind of smaller game studios).
However, if your goal is to learn game development as a hobby (or to start your own game company) you can throw them away and just use what you want. ;-)
Jonathan Blow sure is trying with JAI, inductive.no/jai/
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.