There have been some encouraging developments, of course. But they've had their own drawbacks that are often worse, in practice, than the problems of C++.
D is an example of this. A lot of new and existing C++ code probably could be written in D instead. But D lacks the widespread adoption and support that C++ offers. This translates into there being fewer third party libraries available, which increases the burden on programmers to an extent that's usually unjustifiable during commercial development And this, in turn, helps prevent the adoption of D.
Rust is another example. It theoretically sounds like it could be a replacement for C++, but that's only true in the far future. The language and its standard libraries have yet to show any real signs of stability. We've been hearing that there may be a 1.0 release at the end of 2014, but time is quickly running out on this. Even then, it will merely be where D is at that point. While there may be a fair number of Rust libraries in existence at this point, many of them have become broken due to language or standard library changes, many are woefully incomplete, and many are totally abandoned.
Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases. But the remaining situations where they aren't suitable are large in number and quite critical.
Furthermore, we are continually seeing C++ adapt and evolve. It's getting new features and functionality that these competitors are offering, while still usually giving far more freedom and control to programmers, far better performance, far better portability, far greater practicality, and continued use for serious new software projects. These factors combine to make it an even more difficult situation for potential C++ replacements. They just may not bring enough to the table to warrant replacing C++ for a majority of its users or potential users.
"Furthermore, we are continually seeing C++ adapt and evolve." Indeed. This C++ job trend illustrates this "growing adoption" very clearly: http://www.indeed.com/jobtrends?q=C%2B%2B&l=
I don't dispute that languages like Java, C# and Go being widely used. And while the systems built with them may be critical within a very local scope, such as at the company level, pretty much all software of global importance is still implemented in C, C++, or some mix of the two. This is true almost 20 years after Java came on the scene, almost 15 years after C# did, and almost 5 years Go did.
Go is perhaps the only case where this may change, given how its implementors have expressed interest in porting their existing C code to Go. But that still won't change the fact that the operating systems, databases, and other software systems that Go code often interacts with are still very likely to be implemented using C and/or C++.
If I were moved by these objections, I would conclude that we shouldn't even try to overthrow established programming languages. Heck why not embrace Status-quo Bias altogether?
About Java & co, you need to realized that most C++ code out there didn't need C++ (or D, or Rust) in the first place. The projects that are (i) very demanding to the CPU and memory, (ii) need a complex solution, and (iii) can't possibly separate a few bottlenecks in C from a high level language with a good FFI (Python, OCaml, Lua, Haskell, Lisp…), are uncommon. Some of those projects have incredible impact, but they are still uncommon.
Java & co are for projects where it was a mistake to use C++ in the first place. They don't compete with C++ on its own turf, they just take away territory C++ should never have controlled.
And D isn't a new language, by any means. It has been out there for well over a decade now. That should be more than enough time for it to achieve relatively widespread usage, were it to actually offer sufficient benefit over C++ and its other competitors.
Yeah, it's basically a catch-22: lang X is not a viable substitute because it isn't mature enough/not mature enough ecosystem, and continually and relentlessly stating and reinforcing this point will just keep discouraging people from adopting (and indirectly improving) these languages, since clearly... there haven't been any languages that have been able to displace C/++, so what's the point.
And, according to Pacabel, even if you manage to break through some niche with these languages, most underlying software (OSs, VMs, etc.) will still be written in C/++. So if you reimplement the whole bottom of the stack with other systems languages, only then can you talk about displacement, apparently. A tall order.
Which is why Yossi Kreinin called for help about updating the FQA for C++1x and beyond. As he no longer works with C++, both his expertise and the time he can waste on this language are dwindling. http://yosefk.com/blog/c11-fqa-anyone.html
And you can see the same shrewdness, the same "altruism", the same attention to detail, the same tunnel vision – "this shit I'm working on is so important, it deserves all of my mental energy AND the mental energy of my users at the expense of caring about anything else" – throughout the C++ culture. From the boost libraries to "Modern C++ Design" (the author has since repented and moved to D – or did he repent?..) to the justifications for duplicate and triplicate and still incomplete language features to your local C++ expert carrying his crazy libraries and syntactic wrappers and tangling your entire code base in his net.
So true.
In the beginning of my career, I too was drinking the C++ koolaid. I really believed that manual memory management, large and convoluted class hierarchies, obscure template programming, cryptic exception handling, and pointer tinkering was necessary in a language and, of course, to get good performance you had to use C++. What a complete lie.
I still meet programmers who believe that, because it is important. And then you look at what kind of software they are writing, some desktop app or some web service. Huh.
If you look where the C++ community ended up by C++ programming experience over the years is that you should probably avoid all of that if you want bug free code.
It was a complete lie. Fortunately, none of that stuff precludes you from using C++.
As for the "subjective" part, it doesn't really weaken the argument of the FQA. I estimate most of his "subjective" claims are subjectively true for most programmers.
When something is subjectively true for a sufficiently large majority of the relevant group of sentient beings, asserting its truth, period, is common usage.
I'll grant the FQA as such is outdated, but irrelevant? C++ was a huge mistake to begin with, a giant waste of time at the global scale. (Things are different at the individual scale, because network effects.) Having a heavily documented case for the oblivion of C++ is a good thing.
