(Of course you still want some form of nicer notation than the raw one, but that's beside the point.)
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)
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.)
I just implemented the Haxl paper in Java as a weekend project (for implementing GraphQL APIs), so it totally does ;)
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.
Little abbreviations might be widely used, but when people talk about code reuse I'm hoping to hear about ways to share larger chunks of code, not having shorter idioms.
In Rust, the functions Result::and_then, Result::map, Option::and_then, Option::map, etc. are pretty much all saying the exact same thing, but they need to be reimplemented over and over again. With Haskell, Result and Option (and [], QuickCheck.Gen, Data.Binary.Get, etc.) just need to implement return and (>>=), and they get a ridiculous amount of useful functions for free (mapM_, foldM_, forever, ap, etc.). That's a "large chunk of code" saved in my opinion.
https://hackage.haskell.org/package/base-4.14.0.0/docs/Contr...
And, of course, they also get some very nice sugar in the form of do notation.
Having popular interfaces like monad, applicative functors, monoids etc also suggests common ways to structure any API you are working on.
If you design an API from scratch and have to implement everything again and again, you might be tempted into a pretty arbitrary breakdown of the problem space.
Whereas in Haskell personal laziness drives you to look hard to see if you can express your API in terms of foldable and traversable or monads etc so that you get lots of functions for free.
Those common interfaces also automatically suggest gaps in your API that otherwise you would have only noticed after using your API for a while (or by being a very experienced programmer).
The feature of Haskell that lets you avoid writing 'and_then" over and over is do-notation.
Beyond that, it's not clear that a monad trait would work, even if we did. It may, but it also may not. We'll see (or not) I guess.
You mean you couldn't express it in Rust, even with HKTs? Or you mean that it wouldn't be useful?
There have been some people working on these problems, take https://varkor.github.io/blog/2018/11/10/monadic-do-notation... for example. This is why I say "not clear" and not "impossible" or something. We just don't know.
You can find monads everywhere if you look hard enough. But Haskell actually lets you use those discoveries for massive code reuse, while Rust forces you to write stuff like Result::and_then and Result::map over and over again.
> To say that Rust is a child of Haskell is really overstating the case.
Right, most of these are common influences. I'd say Rust's main contributions are (a) the ownership system, and (b) painting a thin coat of C++ syntax over ML features to make them more palatable, and neither of these seem all that inspired by Haskell.