Woah, the effect system looks really neat at first glance. Also, “region-based local mutation” so your pure functions can use mutation under the hood for performance? Sweet!
I'd like to see an experimental language that leans hard into the concept of controlled mutation.
I always say that purely in terms of design my ideal language is high-level Haskell, low-level C. Conceptually, purely functional design is how programming "should" (note the quotes) be, but doing so down to the level of functions is both not very practical (some algorithms are just easier to express in terms pointers moving around rather than folds, reduces and the like), and makes it hard to reason about performance (especially memory, and most especially if you throw laziness in the mix).
But then again, I write my own stuff in python because I'm a lazy fuck, so probably it's not meant to be :(
> I always say that purely in terms of design my ideal language is high-level Haskell, low-level C.
That's similar to what I used to say. I was devastated to see the BitC project implode, but then Rust appeared and took up the mantle. It's not perfect by any means but it's influential enough to drag the whole field of PL development kicking and screaming in that general direction.
In spite of all the retarded monkeys in its fanbase, I always thought it was an interesting project. Popular languages today are much more similar than they used to be, they are basically "converging", Rust's willingness to try something new must be applauded.
Still many pain points, still a bit of a "puzzle language", too much of a scatterbrain approach in the governance and design direction, but even if it had no other influence than to force people to think about the problems of low-level programming, that would be still a massive plus in my book.
Rust sucks for functional programming because it has no GC. While you get controlled mutation, you don't get anywhere near the ergonomics that it requires.
The reason why Haskell and other popular FP languages all require a GC.
The two have very little to do with each other. What one could say is that higher level functional-like patterns are less idiomatic in Rust, because they abstract away from the low-level control that Rust also provides - which is why Rust chooses to provide, e.g. GAT's as a language feature as opposed to HKT's.
But functional programming is fully supported and lack of GC is not an issue, since you can use Rc<> and Arc<> where needed. (Support for 'pluggable' tracing Gc<> will probably be added at some point, but it will need local allocators, which are not a stable feature yet.)
Oh yes, some basic form of FP is supported in Rust, but it's not the real thing. You can't write idiomatic FP because you really need a GC for that as the reference patterns created by closures are always cyclic. There's a reason why Haskell needs a full-fledged GC.
