Many of those practitioners, do indeed do great talks, but they also live in a bubble far away from 9-5 C++ coders that put out most code.
I advise a CppOnSea 2022 talk, "help me my team is stuck in 90's".
I am sure for many of those people, they do this because they have decided that sufficiently understanding the complexities of C++ provides too little payout (or in some cases none at all) to make the shift worthwhile for them. I don't think accusing developers of "being stuck in the 90's" is the right way to convince them to work differently. If the technology is actually better, you should convince them of such by demonstrating it with many concrete examples.
Contrary to what many seem to believe, just because something is new doesn't mean it is better, even when computers are involved.
I am not surprised by this lack of understanding of human psychology. People will always do the most simple, natural thing that they learned at some point in their lives. You can't expect them to change overnight or even change at all.
A lot of folks who write C in C++ are old gurus who learned their trade long ago.
Ah, blaming the tools: the Hallmark of a master.
Take a moment to think about the problem. You're in a multi-team project, with a few millions lines of code. You're paid to deliver results and meet the client's requirements, and you're already behind schedule. Suddenly the C++ standard committee releases a new C++ standard. What are you going to do? Are you going to
a) continue working on your tickets, or
b) are you going to drop everything to spend weeks updating tooling, projects, dependencies, and put up a series of workshops with the purpose of getting everyone onboard the new shiny toy?
And did you noticed that option b) adds absolutely no value at all?
It's great that you can flip a flag and turn your hello world project into a C++20 project with no work at all, but real world teams that are in the business of outputting real world production-ready code requires a bit more caution.
For instance, I still recall from a previous project I worked with how a n upgrade to C++14 led a dependency to over-eagerly jump head-on to constexpr which caused weird and non-trivial linking errors that took a week or so to sort out. And constexpr wasn't a new addition in C++14.
Do you think that's an unavoidable law, or is it something accidental that could have gone better?
Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size?
I'm curious who you blame, if you don't blame the tools. You could try to blame people. Or one might say it's just how things are and we can't do better.
I'm just not sure if you see this as unavoidable, or if it's something else that makes you say that? You got me curious.
It was the result of having to develop production code in the real world, reusing real world production code developed by third-parties.
In my particular case it just so happened that the upstream dependency exported interface headers that conditionally defined stuff with C++14 features in spite of what shipped with their binaries. Stuff using constexpr ultimately resulted in tons of hard to track linking errors.
> Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size?
This was not a C++ problem. This was a problem caused by the way this particular project was designed to toggle C++14 features when they should not be toggled.
Just because problems emerge when updating a project to the next language version, that does not mean the language is held to blame.
This is one of the reasons why I firmly believe half the people in this thread talking crap about software updates and bumping programming language versions are quite frankly talking about stuff they know nothing about and have zero real world experience. There's far more stuff going on in a language upgrade than flipping a switch and rebuilding a project, specially if upstream dependencies made some less-than-advisable decisions on how to release their work.
In C++ if you aren’t able to build your entire stack of dependencies from source you are gonna have a bad time like this at some point. Any prebuilt libraries you depend on better be pure C, headers included.