monadless VS blog-comments

Well `RecordWildcards` has been around for 14 years... but even without it instead of `{..}` you'd just have `_`s. The main thing that is different is that your Kind example had nested case statements while your Haskell example tried to match everything on one shot, which makes for a non-equivalent comparison.

> Not sure how that could work, though. Idris had an interesting syntax, but IIRC it wasn't general.

I assume you're talking about idiom brackets for applicatives? The general syntax is given in something like https://github.com/monadless/monadless. The idea is to basically take async-await syntax and generalize it to any monad.

So e.g. your `Maybe` example (using `!` for the equivalent of `await` for concision) would look like

  Maybe {

> If anything, async-await feels like an extremely non-functional thing to begin with

It, like many other things, forms a monad. In fact async-await is a specialization of various monad syntactic sugars that try to eliminate long callback chains.

Hence things like Haskell's do-notation are direct precursors to async-await (some libraries such as Scala's monadless https://github.com/monadless/monadless make it even more explicit, there lift and unlift are exactly generalized versions of async and await).

This was a great article, very easy to understand without leaving out the fundamental pieces (the saga that is async implementation difficulty). I think I can even boil this situation down to Rust having it's Monad moment.

It's in this (HN) comment thread and a bunch of informed comments on the original article:

https://github.com/eeeeeta/blog-comments/issues/10#issuecomm...

https://github.com/eeeeeta/blog-comments/issues/10#issuecomm...

https://github.com/eeeeeta/blog-comments/issues/10#issuecomm...

The comments are correct in my view -- Rust can't/shouldn't do what Haskell did, which was to create use a general purpose abstraction that is essentially able to carry "the world" (as state) along with easy-to-trade chained functions on that state (whenever it gets realized). Haskell might have solved the problem, but it has paid a large price in language difficulty (perceived or actual) because of it, not mentioning the structural limitations of what Rust can do and it's constraints. The trade-off just isn't worth it for the kind of language Rust aims to be.

Realistically, I think this issue is big but not enough to write off rust for me personally (as the author seems to have) -- I'd just do the move + Arc shenanigans because if you've been building java applications with IoC and/or other patterns that generally require global-ish singletons (given example was a DB being used by a server), this isn't the worst complexity trade-off you've had to make, though the Rust compiler is a lot more ambitious, and Rust has a cleaner, better, more concise type system as far as I'm concerned.

I think another thing I've gained from this article is another nice little case where Haskell (if you've taken the time to grok it sufficiently, which can be a long time) offers a bit of a nicer general solution than Rust, assuming you were in a world where those two were actually even substitutes. In the much more likely world where you might compare Rust and Go2, this might be a win for Go2, but the rest of the language features would put rust on top for me.