This is an interesting reply Note that c/c++ can be made safe, for instance tcc adds runtime bounds checking. Memory could simply be runtime checked. Problem s

This is an interesting reply Note that c/c++ can be made safe, for instance tcc adds runtime bounds checking. Memory could simply be runtime checked. Problem solved You make a good point as to why we don't. Ada has done exceptionally well at doing what you ask for a very long time. It is not hard. But we don't Hubris is maybe the right reply People deliver code without full line and fuzz tests: probability of code being correct; low-to-zero. This is independent of 'seems to work' c/c++ memory safety. It suggests the problem is deeper We just assume we're safe and correct, and know best; and then live as battered spouses of our own hubris Alternative POV: we allow sharp knives in kitchens. Kitchens are unsafe as a result. It is maybe unavoidable. Road safety causes more deaths than code safety. We allow it. A lack of safety is inherent in any complex system Spark, Coq, provers are great. But unbounded systems quickly become unprovable. Unbounded memory allocation is one of those -- whether 'safe' or not I think this is a major reason missing from the debate. Safety hinders and complete safety is completely impossible However the truth probably lies somewhere in the middle Since you are right: computers are fast enough that even 3d games could often have memory safety In conclusion The current memory safe languages remove more from the table than I think you expect; and that is why I would suggest most important software has been written in 'unsafe' languages For instance, servo arguably demonstrates that. A surprizingly small amount of firefox has been replaced by rust, and not due to lack of effort But also we simply don't care about correctness enough to get closer to it. So I would say it is good you ask for that But too often, to me, the debate looks like we swap one blindness for another