Rust obviates the need for many uses of these monads, either by not requiring purity (so no IO monad), or by enabling controlled mutability (so no State monad).
Out of the remaining monads that are in common use (Result, Option, Future), it doesn't seem particularly worthwhile to try cram them all into the same API, when you could instead try to design better specialized APIs (as has been done with Future)
The monadic interface is not the only API surface those types have in Haskell. It very rarely is. There’s no “cramming,” they either have monadic structure or they don’t, and if they do it’s very convenient to be able to treat them as monads.
Just to be pedantic, we also recently got applicative-do. So you can use a subset of do-notation for the much more prevalent Applicative Functors, too.
In practice applicative functors are even more prevalent than their subset, monads.
If you can express your algorithm using the weaker applicative combinators only, there's more opportunity for optimisation and parallelism. (And the code is easier to understand for your readers, because there are fewer interactions for them to worry about, too.)
That sounds super neat! Haskell always has me jealous of language features, but I’ve committed to focusing on mastering C# and the CLR right now because it’s what I get paid for.
What about the Parser monad? Or the Validation Applicative?
I think you're being a bit short-sighted here.
I fully appreciate that it might be extremely difficult to accommodate these HKTs, etc. in a language with the core values of Rust. That's absolutely fine, because that's probably several research-level projects in and of itself. OTOH, we shouldn't discount the value of such things.
It's absolutely fine and reasonable to choose e.g. efficiency over other things, but it's not the only value.
