Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

My goalposts are immobile - they're my lived experience.

My experience is the voluminous output of static analysers is not mostly legit - it's mostly false positives. But the time taken to establish that they're false positives is huge, because you have to check each and every instance and work out what annotations are needed to convince the analyser that this instance is legitimate, without simply going for the "big hammer" of "trust me, I know what I'm doing" (which is the very thing we've agreed humans are bad at using, because virtually all C++ is "trust me" in this regard). This is why, IME, you get more than one problem per line of code on average when you start applying C++ static analysis tools; and getting people to rewrite all 10M lines of C++ in static analyser friendly C++ is a huge demand to make of them.

Compiler errors are a lot less problematic, because compiler authors take care to not put warnings in that have a large number of false positives, but then you have a huge number of false negatives, because the compilers don't error on constructs that are conditionally UB unless they are completely confident that the condition that makes it UB holds true in all cases.

Rewriting things in a much less forgiving language helps, because the static analysis of the less forgiving language has orders of magnitude fewer false positives, and the annotations needed to help the static analyser understand what we're doing are correspondingly simpler to add in the cases where it gets it wrong. On top of that, it's easier to motivate people (social issues, again) to rewrite into a new, "fun" language than it is to get them to drop decades of misconceptions about "safe C++" and start writing static analyser friendly C++.

void foo(int x) {
  int y = x;
}

That problem would just automatically fix itself and pretty soon (by historical timeline: around 5 to 10 years from now).

The majority of the software written today is made to solve problem that don't exist and funded by money that are hallucinated into reality by belief that one may get something for nothing.

After collapse of western civilization such software would stop being written which would give enough resources to write things “properly” (that's not hard, just make “no liability” disclaimer illegal like it's not legal in most other industries).

But that discussion is way outside of scope for what we are discussing here. I agree that as long as software which works only by accident and couldn't be trusted is considered the norm C and C++ would continue to thrive.

Sure, and if Open Source is going to stick to ancient languages because nobody's got a stick, then that's fine - it'll become the choice of people who want their systems to be buggy, crashy things.

Practically, though, I observe that skilled engineers don't want their code to be buggy; no-one skilled in the arts is writing UB in C or C++ because they don't care about bugs, they're writing UB in C or C++ because the set of rules you must follow to avoid UB in C or C++ are neither simple enough to stick around in memory, nor trivially machine-checked so that you get reminded when you break them, nor only applicable in a small subset of your program. As a matter of pride, those people are likely, over time, to switch to a language that makes it easier for them to write code that has no bugs (performance bugs, correctness bugs, any other sort of bug), because they don't want to be well-known for writing code that's buggy.