> How much, of what is exposed as the complexity of a language, could be realized in the form of sequences of optimizing compiler passes, perhaps automatic or p

> How much, of what is exposed as the complexity of a language, could be realized in the form of sequences of optimizing compiler passes, perhaps automatic or perhaps flag-driven, such that the programmer user experience remains clean-ish yet the sophistication of generated code is on par with a language like Rust? This is an excellent question, and one the Dylan designers wrestled with in the 90s. How could they make a high-level language with many of the best features of Lisp, while still making it possible to perform like C? The strategy they chose was: 1. Offer powerful features with simple interfaces, even though performance was poor in some cases. 2. Provide "fast path" versions of these features that handled common cases with high efficiency. This turned out to be something of a disaster. Compiler implementors needed to implement the slow path, plus code to detect when to use the fast path, and finally the fast path itself. This ended up being 3x the work of just writing the fast path. And to make things worse, users never really knew what constructs would cause them to hit the slow path. (And yes, this is similar to the challenges SBCL faces, but SBCL has had a lot more time to work on them.) Rust has two major sources of complexity: (a) the ownership model makes certain common architectures much harder to write (particularly with GUIs and non-ECS games), and (b) Rust cares about references and memory layout and lots of system-level stuff like that. The latter is hard to abstract away without losing performance. I love Rust, and I look forward to seeing a new generation of languages remix its ideas. But I don't think that pairing a default-inefficient language with a "sufficiently smart compiler" is the best way to get there.