Defective C++
yosefk.com
yosefk.com
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++.
I don't agree. If someone is programming in Python, they are programming in Python. They aren't programming in C, in addition to Python, just because the VM or whatever is programmed in C. If some language displaces C or C++ in some niche, then it has displaced it, even if the VM of the implementation of the language happens to be written in C or C++. The important distinction, I think, is what people are programming in.
This is like saying that "nothing has proven to be viable alternatives to cement for building houses" when talking about building entire houses with cement, if the foundation of houses are always made up of cement. The fact that the rest of the house can be built with other materials like wood or bricks is a crucial point, in that context.
Sure, as I said, C++ has some place, but nowhere near being the one and only language to implement such stuff, including database engines, webservers and operating systems.
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.
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.
My point is, if you can abstract the underlying architecture, you can replace it. It's difficult because most complex abstractions leak, but it has been done in the past. That Javascript virtual machine written in C++ could be re-written in Rust.
So, even if displacement means "you are not even allowed to use C/C++ as a target language", and "you are not even allowed to use OS services written in C/C++", we can still "displace" C and C++. It won't happen any time soon however. I believe we need to wait for something like mainstream FPGAs.
The problem with current processors and C/C++ is, they tend to be optimized for each other. If instead we had something like an FPGA running at desktop speed, programs would be compiled to logic gates instead of being compiled to assembly. This would dig a grave for C++.
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.
You say D is sufficiently old, that it's lack of adoption is significant evidence that we should never adopt it. The problem is, most people think like you do: they wouldn't adopt a language before it has some visible traction. The corollary is, new languages never get widely adopted, unless of course some Big Corporation does massive publicity around it (Java, C#…). The real reason D isn't widely adopted, is not because it's not better than C++. It's because it was not widely adopted in the first place. Textbook chicken and egg.
You speak of benefits and downsides of a language, but what you are really speaking of is the whole ecosystem as it is now. You don't even look at the long term potential.
Also, put yourself in the shoes of a language designer. Say you have a brilliant programming language. Experimental quantitative research has shown with no ambiguity that your language is better than some established, old language in its own niche (20% more productivity, 10% less post-release bugs, same observed runtime speed and memory consumption…). Just one little problem: your language have zero users, and only a little standard library. How would you get people to adopt your new language?
Hint: people won't believe your peer-reviewed experiments. People will refuse to learn a new syntax. People will want to reuse their old code. Even if you come up with an automatic translation tool, people will not trust it. People will say the benefits of the language are outmatched by the drawbacks of its standard library (too small), and of its community (none to speak of). People will be afraid of the required training (even if your research shows productivity benefits after a couple weeks).
How do you fight Status-quo Bias?
Personally, I found only one answer, which unfortunately isn't applicable everywhere: making the new language's implementation so cheap that all it's costs are paid off in a single project. DSLs may do that: with the right tools, a small external DSL can take no more than a couple hundred lines to implement.
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++.
The standard library has become so much better then the old days. Now I can even create threads without extra libraries. Unfortunately std types are no longer COW with C++11.
Now if I only can get rid of that awful header file I almost have something that works without too much headache and profanity.
GNU std::string being CoW (still is atm btw) has always been deceitful. The API was simply never designed for that implementation, which resulted in seemingly cheap read-only operations (char x = str[42];) becoming quite expensive.
I'm glad you mentioned actually, since API authors embracing reference semantics through fear of overhead is a great rabbit hole of systemic complexity for C++ developers who are then forced to swim against the tide in the language. Sadly I don't think Rust goes far enough in bringing love to value semantics.
In what other language has so many Stack Overflow threads and blog post been dedicated just how to pass a simple parameter to a function. And with C++11 we have one more way of doing it. It is really mind-boggling.
I never have this problem in other languages and I can do equal the heavy lifting.
And for the C++ programmer it gives a false sense of satisfaction when spraying the code with const& everywhere. I saved performance!
Just bizarre.
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 think Yossi Kreinin's main objection is not the absence of garbage collection in C++, but the fact that so many projects that could use garbage collection, don't.
Like "I need performance!" No you don't. "I really need performance!" My GC is just as fast as your malloc/free. "I don't use malloc/free, I have my own custom allocators, you ignorant Java programmer!" I just use manually managed arrays for that, and enjoy garbage collection for the rest of my data. "My environment can't afford me any GC pause!" My GC hardly pause, and it collects gigabytes of data. "But I know things about my data your GC don't!" OK, now you may have a point.
The performance difference between C++ and a well implemented native language with garbage collection (OCaml, Haskell, Lisp, Go…) is not large. Definitely less than an order of magnitude. Your constraints must be real tight to force you to give up garbage collection.
In the vast majority of projects, not using garbage collection is a problem. If not with the language, at least with the community.
---
I think Yossi Kreinin don't object the knife itself. He objects the fact that people actually try to eat soup with that damn knife, spilling soup and cutting their tongue in the process. Sometimes, we do need sharp edges (for cutting meat). But for much eating activities, sharp edges are just a hindrance.
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.