The real problem with C (and to a lesser extent C++) nowadays is not just memory leaks or segfaults, but all the security vulnerabilities you get from the lack of memory safety.
Your code might work 100% correctly for your users, but it may also put their system into risk when processing arbitrary and potentially malicious data. When your system needs to handle data that may come from anywhere - and almost every system does - writing Herb Sutter-correct code is no longer just a nice-to-have.
A big part of the point I meant to make is the difference between theoretical problems and practical problems, and how priorities and risk vary a lot across applications. The number of complaints I've received about malware targeting my games over the last 25 years is exactly zero. So when I go looking for my perfect language, that's not a problem that I'm trying to solve. I'm not arguing that other languages shouldn't exist, I'm saying they don't address the most important problems in my domain (roughly, expressiveness and performance).
> A big part of the point I meant to make is the difference between theoretical problems and practical problems, and how priorities and risk vary a lot across applications.
And this is how we had ILoveYou and similar viruses. In the name of the whole
internet, I hereby thank you very much for your hard work in this matter.
That might be the chorus when it comes to selling new languages, but there is no reason C could not be compiled with memory safety. It is not done because by the end of the day people don't care for safety much.
It's obviously not happening because C's design... especially lack of any guarantees... combined with what those checks required made complete, memory safety hurt performance a lot. Talking multiples worse (300+%). Things like Softbound+CETS and Criswell's SAFEcode have gotten it down below 100% worse performance in many cases. Others seem to explode in delay on specific routines due to how they interact with the bookkeeping methods.
Whereas, Ada, Wirth, and Eiffel languages were designed to make the job easier for users and tooling. SPARK was even tailored to make it easy to prove absence of C-style vulnerabilities with automated proving. That was done by a small team over a period of years whereas global assortment of teams putting decades into static analysis or proof tools for C haven't pulled that off outside even more restrictive tools like Astree Analyzer.
C is just inherently bad for safety despite safe ways of doing it existing. That's because it was designed almost exclusively to run fast on a PDP-11. That simple. On other end, Hansen wrote Edison for a ultra-minimal language for a PDP-11. It was smaller than C, easier to process, and still had safety features. Reiterates it was simply a personal preference by C's designers to not care about safety while many others did.
Your code might work 100% correctly for your users, but it may also put their system into risk when processing arbitrary and potentially malicious data. When your system needs to handle data that may come from anywhere - and almost every system does - writing Herb Sutter-correct code is no longer just a nice-to-have.