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 e

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 the simple thought that design & implementation of async in Rust has driven it to it's first "monad" moment. The question is now largely whether there exists a way that is better than monads to handle this problem. 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#issuecomment-795098853 https://github.com/eeeeeta/blog-comments/issues/10#issuecomm... https://github.com/eeeeeta/blog-comments/issues/10#issuecomment-795151809 https://github.com/eeeeeta/blog-comments/issues/10#issuecomm... https://github.com/eeeeeta/blog-comments/issues/10#issuecomment-795369243 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<T> 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.