I wonder about analysis tools for c/c++. I know those tools have come a long way. Is the problem the decades of time where those tools were proprietary or expensive or free/open and poor in quality where most of this code was written? Or do these tools actually fall short of their claims of memory safety and the only solution is a rewrite? Or I guess it can be like opening an old solution in visual studio seeing it has 100+ warnings or doesn't even build anymore with current tooling so changes go on the back burner because that small change turns into a few days of work because nobody has built it in the last 10 year's...

Rust + ATS please. But the problem always is interoperability.

People do the C/C++ S&M thing because of interoperability.

You cannot call Ruby from Python or vice versa, but you can call C/C++ from both Ruby and Python.

This is one of the main reasons why people do not change.

We need a better portability layer, Dlang/betterC can be a solution here, but we have to be brave and forward looking.

The alternative is live forever in a worse-than-cobol self-inflicted hell.

C and C++ are NOT the same language. If you are writing modern C++ you don't have nearly the memory problems. C++ lets you use/create the C backdoors, but that is something that should only be done when you have to - when you have to are times you either cannot use the alternative language, or you do, but those languages suddenly become just as unsafe.

Yes there is a lot of old C++ out there. But you can do better in C++ without losing the old features that have been debugged over the years, and without all the money of re-writing things that might or might not have bugs.

modern c++ provides fixes for everything he mentions in the article without completely swapping out all the experience gained from decades of existence. People just aren't using it enough. It's all there.