He conclusion is the C++ is obsolete and the power of new hardware capabilities is being squandered because of it. I'd call that 'scathing.' I'll always be fond of C++, but I hope I never have to use it again.
The only arguments presented by the author are his own subjective opinions of how bad various features of C++ are. There's merit in many of his arguments but the effect of each problem is exaggerated way beyond it's actual impact. For example, the bold, unhedged claim:
"Two words: data races. Imperative languages offer no protection against data races — maybe with the exception of D."
is a ridiculous claim to make right after his (mostly dismissive) nod to memory model and synchronization primitive introduced in c++11. If it was that difficult to implement parallel programming in imperative languages, we'd have to scrap every OS kernel (which pretty much all scale to large number of cores today) and every hosted language environment (which are all ultimately written in C/C++) and rewrite them in Haskell.
Careful readers (who read the references at the bottom of the article) will note the author clearly has an agenda having to do with more automated resource management in C++. For whatever reasons, it has not found it's way into the standard until now and in his frustration, he's lashing out at not just C++ but basically the entire installed base of computer technology (mostly built on top of imperative, manually memory managed languages like C and C++).
> That conclusion on squandering the power of new hardware is being backed by absolutely zero data
I believe that the C++ language and its philosophy are in direct conflict with the requirements of parallel programming. This conflict is responsible for the very slow uptake of parallel programming in mainstream software development. The power of multicore processors, vector units, and GPUs is being squandered by the industry because of an obsolete programming paradigm.
It's his opinion.
> and is obviously false
That's your opinion.
It's not an opinion. It's a simple matter of observation. I see software all around me (and I write some of it) written in C/C++/Java and other imperative languages scaling perfectly fine on large scale multicore systems. I use linux, OSX, Android and iOS on a daily basis. Almost all the code running on these boxes is written in imperative languages, much of it written as parallel, shared memory code.
Google (where I used to work, but I don't think I'm revealing any secrets here) runs a gigantic cluster on foundational software almost entirely written in multithreaded C++ with the kernel written in C of course (some of the application level stuff is in other languages, but still a whole lot even at that level is in C++). Almost any large scale, parallel computational systems you could name are written in imperative languages.
To call all of the above "just my opinion" is simply denying reality. There's no further argument to be had unless there's a basic, shared reality ground to stand on.
The argument was about squandering the powerful multi-core hardware because of deficiencies in imperative languages. No notion of some platonic ideal of a parallel application was raised.
My point is that the "squandering" claim is clearly and obviously false as I argued above.
Pointing out that most parallel systems are written in imperative languages doesn't help. Most systems in general are written in imperative languages, so it's unclear what you're even comparing it to. Imagine standing on a street corner in 19th century England saying, "What do you mean that open sewers aren't as nice as closed ones? Look at all these sewers; they're all open!" Similarly, "but dude, Google!" just isn't responsive to the argument at hand. An easier-to-grapple-with framing might be: if FP languages continue to grow in popularity, will it become much easier to build parallel software?
I don't actually know, and I'm not even claiming you're wrong. And it's a predictive claim, so you could argue the semantics of whether it's an opinion or not. But your argument sucks and your pretense that your view is some sort of law of nature is lame. It's completely reasonable for someone to disagree with you on how good C++ is for parallelism.
"Ease of writing parallel software" was never the question we were arguing.
You wrote this at the top of the sub thread:
> If it was that difficult to implement parallel programming in imperative languages...
Now you want to make it about squandering. You seem more focused on being right than having a discussion.
...and this is true. An imperative language (in and of itself) has no protection against data races. That's not to say that imperative languages can't have code without data races. It just means that the language itself offers no protection.
Functional languages (basically only Haskell - I consider Scala an imperative language) have protections due to the Church-Rosser theorem[1], which states that (in essence) pure code can be executed in any order and there won't be any race conditions.
The rub (which is what I think you're getting at) is that it's dubious whether languages like Haskell are practical in a real-life production environment. Imperative languages "get things done", and given judicious use of appropriate libraries may be able to do concurrency just as well if not better than a purely functional language like Haskell.