By far the biggest demand for HKT is from people who are requesting Haskell-like do-notation for error handling. HKT would affect everything! Given this, I absolutely agree with the notion that HKT is a 2.0 feature rather than a 1.0 feature.
> By far the biggest demand for HKT is from people who are requesting Haskell-like do-notation for error handling.
That hasn't been my experience -- we are constantly running into cases in the libraries where we need HKT to express signatures in traits. The simplest example is talking about iterator return types, which often need to depend on a lifetime. See the collections reform RFC (https://github.com/aturon/rfcs/blob/collections-conventions/...) for details on that example. There are many, many others.
I suspect that HKT's role in Rust will be much more about extending the trait system for generic programming, rather than full-blown monadic programming.
Thanks for posting this link. I struggled with this problem all yesterday, and hadn't realized that rust can't handle lifetimes over traits until you posted this.
Unfortunately without HKT you cannot model monads, abstractions that are useful for a wide range of use-cases, one of which is error handling.
In my opinion it is a pity that HKT wasn't there from day one. I had high hopes for Rust, because in comparison with languages like Go, it didn't take a stance like generics are hard, lets go shopping. And personally I can see problems with such pragmatic approaches, because such features have to be baked in, otherwise they'll either never make it or they'll suck.
And then we are back to square one - C++ and Java forever.
> In my opinion it is a pity that HKT wasn't there from
> day one.
I think this shows a misunderstanding of the genesis of Rust. :P Literally the only feature of early Rust that has survived to the present day has been the use of `unsafe` blocks to cordon off bits of code that cannot be statically checked for safety (I don't count things like generics as having survived from early Rust, because early Rust used Java-style virtual dispatch for generics rather than C++-style monomorphization (nor did it have typeclasses, because traits weren't conceived until later)). From day one, the goal has simply been to make a systems language that was safer than C++, and it's taken years to figure out how to do that effectively. And as a goal-oriented language, features are cheap: Rust has thrown out more features than most languages will ever have. The fact that HKT aren't there yet is because they're merely a nice-to-have rather than strictly necessary (in the way that lifetimes are strictly necessary), and because Rust has never particularly valued maximal expressivity in the way that e.g. Scala has. In the meantime, just because generic monads aren't possible doesn't mean that monads can't be approximated for specific types like Result and Option, and the lack of them isn't going to prevent Rust from its goal of being a replacement for C++.
