| It must be hard to design a zero-cost abstractions language. It seems that there are more and more terms and concepts that come up in order to support more directly-pragmatic PL features.[1] Reminds me a bit of how Haskell comes across to me from the outside with all its GHC extensions. Haskell is a research language but other more specialized functional languages have the luxury of being able to theorize and implement more orthogonal and perhaps more “elegant” concepts and approaches. (Again, merely an impression from the outside.) Consider the design effort behind parametric memory allocators. That seems like a pretty cutting-edge problem. And yet I bet the Rust folks knew that they would want/need to do this way before they started doing that work in earnest, because people from C++ seem to want the same thing (if they don’t have it already?). I idly wonder if one could, if one was in a similar position as Rust was some years ago, just go ahead and design a full-on unapologetic type-level programming language from the start. Because you know that your type-level terms will be worthy of the moniker “language” eventually (and it might not be a compliment as such). Just a nice, high-level language that doesn’t bother with the “bare metal” concepts that Rust the value-level language has to deal with. (Can it even be done? Don’t ask the peanut gallery about that.) Either that or you accidentally build an emergent language that Gankro can write an article about one day titled, I don’t know, Shitting Your Pants With Higher-Order Unsafe Unwind Type-Level Allocator Escape-Suppressing Storm Cellars. [1] In this case: you have more use for compile-time integers than something more general like being able to describe that two nat-indexed lists are of the same length, like you can in Idris. |