Totally agree. C++11 was a huge disappointment to me - rather than taking to opportunity to make changes that would help attract new C++ programmers, the committee decided to allow the "C++ nerds" to pile on even more complexity to their already overwrought libraries (cough boost cough).
C++ is a tool for power users, not a popularity contest.
Changes to the language should not be done just to attract more users. This is especially true if these new users would be today's PHP, JavaScript and Ruby users. The C++ community is much better off without these kinds of programmers.
It's much better for people to use C++ when they realize that they need the powerful functionality it offers, rather than dumbing down C++ in a way that'll make it attractive to less-skilled developers.
"It's much better for people to use C++ when they realize that they need the powerful functionality it offers"
Relevant anecdote: I know a number of C++ programmers who said they would use Haskell / Python / etc. to "prototype" a system, then switch to C++ when they needed what C++ has to offer. None of them made the switch back to C++ and their "prototypes" became finished products.
> None of them made the switch back to C++ and their "prototypes" became finished products.
This is because the vast majority of the time people's claims of performance requirements are complete BS. If you're writing true system software (an OS kernel, a database, an MQ system, etc) then shaving microseconds is going to matter because 10s, 100s, 1000s or even more applications built atop or using your code will be leveraging the minor gains you are creating. If you're building "Misc App X" then it's probably not going to matter.
Author of blog post here: That has been my experience as well. People tend to overestimate their performance requirements. Then, in the name of improving performance, they do all kinds of things that bring down their productivity and increase the complexity of their code (choosing C++ as the programming language is one of those things), but they never verify if any of those things really made enough of a difference, if any, to create value.
Another thing I noticed is that of those people who do have serious performance requirements (OS kernel etc.), many choose C over C++. We all know what the most famous example is. I have no experience in this area. I wonder if there is any data on the use of C vs. C++ vs. other languages like Go in that realm.
Another Relevant anecdote: I personally prototyped a complex data transformation in Clojure in about a week. I then had to re-implement it in C++ which took about three more weeks, but was actually able to perform near to the speed of the super fast raid HDD (~1gBps). The clojure code (even after a lot of type hints etc) never got past 60MB/sec throughput, which would be a showstopper for a tool that has to process a lot of data online.
Languages like Haskell and Python being suitable for many applications in no way changes the fact that there are many other situations where they would not be suitable, and a language like C++ would be needed.
Keep in mind that there are also many cases that are the opposite of what you describe. I've worked with many systems that were initially implemented in a non-C++ high-level language, yet the developers had to go back and start incorporating C or C++ code at some point for various reasons, if not re-writing the entire system in C++.
The hybrid approach that Python allows for is extremely powerful, given how it makes calling down to C and C++ code from Python code quite trivial, or embedding a Python interpreter within existing C or C++ code.
