I know, and I can provide similar quality reference from Microsoft own samples if you wish.

I don't get the point you're trying to make, sorry. "Big companies sometimes write crappy code" is of course going to be true.

It would be interesting to see statistics on use of newer C++ in companies known to have relatively stringent coding standards and code review regimens. I suspect that it (still) isn't so much about crappy code as much of the value of C++ being sunk into legacy code that determine the constraints put on *new* codebases.

Most companies still write C++ crappy code, regardless of the advocacy many of us in the community try to make.

In fact, if we focus on traditional enterprise shops they are stuck in what I call the C+ mindset.

Those of us that bother to live in HN, Reddit, attend CppCon, C++Now, C++ on Sea, ACCU in whatever form, are 3lit3. A tiny minority that actually cares about quality.

That is the point.

It doesn't sound like much of a point. The same thing is going to be true for all programming languages widely used in industry. It's not a C++ issue.

In fact, see Python 2 vs 3 for probably the most impactful case of people being slow to take up new language versions/features.

There's going to be shops writing C89. Some reasons might be well founded, some reasons might be less well founded.

Correct, so now imagine Python 3 as the adoption of Core Guidelines, which is basically what modern safe C++ is all about.

Lasted surveys, which are anyway only answered by people that are active enough to care about stuff outside job, places use of tooling to validate modern practices at about 20%.

Now do some statistical extrapolation and it is relatively easy to find out how much "modern C++" is actually used in practice.

Bjarne hasn't dedicated two CppCon to the subject to improve adoption of better C++ practices just by accident.

I agree. I think perhaps the one thing that does more uniquely affect C++ is the compatibility with C (at least not newer versions of C) and the strict backwards compatibility with C++ before it. Which is a little strange to say because compilers _do_ deprecate features, so it's not strict-strict, just strict enough for the standards committee to use it as an excuse.

The people who write crappy modern C++ will write crappy C++03, crappy java and crappy golang.

Well, 50% of programmers are at most mediocre—or worse. And only maybe 1% of programmers is able to write significantly better code than all others.

So in result, just by the means of statistics, all code is necessarily crap. (Besides the extremely seldom pearls written by some independent geniuses).

Frankly this is unavoidable on an industrial scale of production, I guess. At least as long as we can't clone "10 x programmers".

Perhaps, but crappy Java and crappy Go won't have memory corruption concerns, which is a huge plus in and of itself.

Indeed, unfortunately they get to play with sharp knives.