A few things:
1) Writing concurrent code in C++ is exciting (this is a bad thing). Processors are not getting much faster in serial execution, but the number of cores are continuing to increase
2) Programmer time is (usually) more costly than anything else in your organization. I'd argue that for most organizations, they're not making enough money per unit of throughput to justify the excessive programming time.
3) C++ is not designed for operators. Rust has this problem too. Once you know how to inspect a Java, Erlang, or Go program, the tools become familiar.
First, OpenMP isn’t that bad. Second, the author of the article you’ve linked forgot about another kind of parallelization, SIMD. Realistically, SSE and AVX instructions are only usable from assembler, C, C++, and Fortran.
Sometimes throwing hardware at problems don’t work. Either because it’s technically impossible (console games, mobile) or because you don’t own the hardware (PC games, desktop software). For such products, either you spent “excessive programming time” programming C++, or you won’t release any product at all.
More here: http://joearms.github.io/2013/03/28/solving-the-wrong-proble...
2) Programmer time is (usually) more costly than anything else in your organization. I'd argue that for most organizations, they're not making enough money per unit of throughput to justify the excessive programming time.
3) C++ is not designed for operators. Rust has this problem too. Once you know how to inspect a Java, Erlang, or Go program, the tools become familiar.