The thing I like most about Rust is that it is still a practical language where I can still solve my problems in different ways and always know what will happen. I also care about the "how" and not only about the "what".
Everything being F[_]ed is what I do not need anymore.
If someone were to create an explicit trait for them and RFC it, they'd probably name it something like Map and Then rather than Functor and Monad.
I think this kind of "you've already used functors or monads, they are just scary names" retort is really missing the point of what folks are complaining about.
I'm not even taking a side here in this thread (although I have advocated against functors/monads in the past). I'm saying that your comment is missing the point of folks who are skeptical of things like functors and monads.
No. They are Option and Result and Future.
> You've probably used them without even knowing, because we didn't give it some weird, unlearnable category theory name.
No. I have not used them without even knowing. I have used Option, Result and Future. I do not need some meta-universe which just makes easy things more complicated by stating some laws which types must hold just for the sake of discussing them and have the one ring to rule them all.
It's not a ring, it's a monoid; there's (in general) no negation.
Don't you find it intriguing and interesting that these seemingly different types have these commonalities?
And I have to admit that I find these commonalities very fascinating. I can still remember how I enjoyed applicatives and the like when I started with scalaz back then. Whether the model becomes simpler? I do not really know. I just found out for myself that I do not need this knowledge at work and that it didn't really help me to solve my daily problems. This is actually what drove me to Rust which in my perception is a nice practical "in between" (I know it also is no silver bullet).
Combine that with GHC's optimizer and it's no contest which language to choose if both ergonomics and performance of code written largely as lambdas is your priority.
It's not so much the GC, as it is "in a GC'd language, everything is on the heap and a lot of information (from Rust's perspective) is erased." You may be able to get rid of GC in some sense, but you'd end up with something halfway to Rust, not the whole way.
That makes sense, thanks for explaining that, I am used to Haskell but never used Rust.
That said, -XLinearTypes in GHC 9.x will open up a world of memory management capabilities in library-space for Haskell. Very exciting stuff! If you push the heavy stuff off-heap, then the GC just becomes a slightly fancier arena allocator.
You can also have the RTS manage the memory itself, but have complete access to a pointer to raw memory. That doesn't work if you have pointers in the raw memory ofc, but it is a nice option if that's not the case.
Unfortunately we don't yet have covariant associated types, so my GC is a pain to use.
In all seriousness, I'm not sure if Rust will ever be a great fit for abstract high level programing. The syntax is just too verbose, and lifetimes are a leaky abstraction. It might make a good compiler target though. At the very least next generation FP needs to have a great Rust interop story.