rfcs

It's not like people are saying "Rust will never have M:N threading", it's that the current implementation didn't offer enough advantages for the disadvantages it brought. https://github.com/aturon/rfcs/blob/remove-runtime/active/00... Having done some things with libgreen threads myself, they really didn't give anything over proper threads (especially without segmented stacks). So I am curious how this will evolve in the future.

> 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.

> On minor concern though, I don't see how "where clauses" are simplifying the language. Looks like something that could be added after the release. Where clasues simplify Rust code, they don't simplify the language itself. They're also important for associated items. For more: https://github.com/aturon/rfcs/blob/associated-items/active/...