> a language with all the performance of C without the footguns IMO, this isn't even the right goal. The problem is that in many cases using C is itself a pre

> a language with all the performance of C without the footguns IMO, this isn't even the right goal. The problem is that in many cases using C is itself a premature optimization. Consider two languages: * C, which gives you performance by default at the cost of an entire arsenal of footguns with esoteric nonlocal trigger conditions * Hypothetical language X, which has all the same footguns but engineered for safer triggering and locked up in a safe that you have to choose to open when you want C-like performance I'd rather have hypothetical language X (which is an accurate portrayal of many real existing languages), because it's got better failure modes. Performance issues are less impactful, in general, and more importantly they are more obvious. It is usually easy to tell when code is not fast enough. The endless parade of CVEs ultimately deriving from memory safety issues, often decades old, is living proof that misuse of the footguns is frequently far from obvious.