[clarry]

We can abstract the CPU away. However, undefined behavior is just the tip of the iceberg. You can fix it all you want but we'll be stuck with logic bugs, side channel attacks, info leaks, bad permissions & malconfigured servers, poor passwords, outdated & broken crypto schemes, poor access control schemes and policies, human error or negligence, etcetra.

There is a huge amount of ways security can go haywire even with perfectly defined behavior. Make no mistake, I love watching as unsafe unbehavior is slowly getting fixed, but I think language nerds are too fixated on the UB to see that it's not the big deal and won't get rid of our problems.

Another problem language nerds miss is that we can adapt existing code and tools (in "unsafe") languages to weed out problems with undefined behavior. It's just that people aren't interested enough for it to be mainstream practice. Yet the bar is much lower than asking everybody to rewrite everything in a whole new programming language. So why do they keep proposing that a new programming language is going to be the solution? And if people just don't care about security, well, we would have all the "defined behavior" security flaws in the new code written in the new shiny programming language.

[elihu]

I don't think that better languages will fix all the security problems. (One can, after all, create a CPU simulator to execute compiled C programs in any reasonably powerful "safe" language.) I just think that C and C++ are specifically unsuitable for building secure systems, and we won't make much meaningful progress as long as we're dependent on enormously complex software written in languages that don't at least have some degree of memory safety as a basic feature.