On the one hand, I have many legitimate use cases for higher kinded types in Rust and I hope they land soon.
On the other, I'm extremely worried about how they would affect the Rust ecosystem once everyone starts trying to implement Haskell style category theory libraries.
Conversation
I think the hardest lesson I've learned over the past year and a half of Rust development is that "this is good in Haskell" rarely implies "this is good in Rust," despite the surface similarities between the languages.
Not sure everyone would learn that lesson in time...
4
6
39
I mean, re: mobile.twitter.com/bodil/status/1 - that was a joke and I actually took lenses _out_ of immutable.rs because in the end I couldn't see the point of them, where the use case in Haskell (and Clojure) is obvious.
Quote Tweet
1
1
15
On the other hand, I really do think Rust would benefit greatly from a simple Monad interface so we could have fully generalised do notation instead of this async/await silliness.
6
3
30
Believe it or not we've heard of monads before. Unfortunately, no one's ever come up with a signature for >>= that could work for the monads in Rust.
2
3
That's why I'm waiting anxiously for higher kinded types. It would seem to be a minimum requirement.
1
I am saying that higher kinded polymorphism could not be used to provide a type signature that could abstract over both Iterator::flat_map and Future::and_then.
2
1
2
Yeah, I've been thinking on this, and am curious to explore other options. Perhaps not in Rust though. You might need to do compositions and mapping and stuff in a category of 'iterator adaptors' rather than on the container itself.
Not sure how well the theory works out though, I'm not a category theory expert. Also you might need a more general Functor interface than the one that Haskell traditionally provides.
1
And then you have the fun of actually teaching it. 😁
1