> This slightly over 100 page book on move semantics https://leanpub.com/cppmove shows some of the iceberg like complexities dotted all over the place. Some developers probably never use and have never even heard of move semantics.

I think Scott Meyers' "Effective Modern C++" which is in large part a collection of caveats and description of things which don't fit always together also underlines that impression:

https://www.amazon.com/Effective-Modern-Specific-Ways-Improv...

Hard agree. I was enthusiastic about reading that book when I got it, as I'd been very late to the bandwagon of new C++11 and C++14 features.

Ended the book in a pessimistic tone. It looked more like a cookbook of pitfalls _everywhere_.

Every new feature looked exciting, but came with a list of cases where the language decides to leave you on your own when it gets too uncomfortable (the "well that's undefined behaviour, I'm sorry, you suck! bye!" escape hatch). So in the end it's like you said: a new list of gotchas to learn by heart.

I think in Scott Meyers case it is he basically never used C++ in production, which in some sense is ok, since he makes his living as a language expert, but sometimes this shines through; also from a D conference talk I remember, even he got sick of it and switched to D.

Also let me use this comment to recommand John Lakos, his talks, his books. He knows how to build large scale applications and if you saw his talk on the 'is_working_day' function (if I remember correctly) you know you were not overthinking.

Thanks for the recommendation, I'll have a look at his work, for sure.

Also I'd be curious to see that talk you mention, do you remember anything about it that could help in searching for it?

I think same talk but different recording: https://www.youtube.com/watch?v=MZUJsCh1wOY I think around 1:08:30 onwards (maybe even before) the example I had in mind.

For me, that disillusion has been one of several steps.

Scott Meyers book was one point.

Then I started to learn Clojure, motivated by the idea that we need better concepts for the upcoming massively parallel hardware (a big influence for me was the article "The free lunch is over" by Herb Sutter: http://www.gotw.ca/publications/concurrency-ddj.htm). I now think that immutability by default is clearly the better way to go, even in close-to-the machine applications like embedded devices and industrial control applications.

Then, I saw this article on the different options and syntax for initializing variables in modern C++: http://mikelui.io/2019/01/03/seriously-bonkers.html

And I was like, no, this can't be serious. I think this was the point where I began to distance from the language (though I still use it at work when I need to).

I got also the impression that the actual language use in C++ is undergoing a serious split. Compare the C++ core guidelines with Google's C++ style guide:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

https://google.github.io/styleguide/cppguide.html

This does already look somewhat like different languages, only that they can be compiled with the same compiler.

And then, the C++17 and C++20 standard iterations, at this point it is just like "this is too much! What is this good for?"

My entry in professional C++ programming was accompanied by Scotts earlier books. The moment gradually to refrain from the language as my main tool again coincides (coincidence?) with his retreat.

> if you use it all on your own you don't even see the problems

100x this. If >90% of your serious coding is in one language, you'll become desensitized to its bad parts but you'll be hyper sensitive to anything that seems inconvenient in any alternative. I've seen this over the years with Fortran and C coders. C++ coders do it to C all the time. Lisp coders are notorious for it. It's Selective Perception 101, counting the hits and ignoring the misses. We're all prone to it, and have to correct for it.

If you really want to compare any two languages, you have to give both a more than casual try, and keep an open mind throughout. Otherwise your conclusions are likely to be unhelpful at best.

One can even think of long compile times as a feature (more time for coffee breaks), well or that nightly builds sounds actually cool.

FORTRAN is still quite popular in many fields of scientific computing and C++ hasn't become ubiquitously mainstream so there's probably quite a lot of potential here.

> C++ will eventually peak and die off but the timeframe is probably measured in decades and I'm sure there'll places where it holds on even then, like Fortran today. I certainly would't recommend it to a programmer starting out today, instead C or Rust would be better places to get an idea of system level programming.

Unlikely. The only candidates for replacement are Rust and D, none of these are anywhere near the adoption of C++.

What C++ can do is get better at being a language and then maybe give tools for developers to phase out outdated constructs or relics from C. It is not going away cause it's the best replacement for C humanity will ever get, at least for the next century.

> Unlikely. The only candidates for replacement are Rust and D, none of these are anywhere near the adoption of C++.

Neither C nor C++ have replaced Fortran in that sense, either. Yet, as far as I can tell, Fortran has peaked a long time ago.