This is a really interesting post, and it's predictable if disappointing the degree to which the comments are rehashing all of the same tired arguments about as

This is a really interesting post, and it's predictable if disappointing the degree to which the comments are rehashing all of the same tired arguments about async rust. I for one am pretty satisfied with async rust, and I'm excited for the stabilization of async-trait. I'd love to see some of the improvements discussed in this post come to fruition. Generators in particular are something I've found myself wanting on multiple occasions, because writing custom Iterators is relatively complex. The point about return-type notation is really interesting. Once async-trait is stabilized, we'll probably go through and rip out as much usage of the `async-trait` macro as possible, so I'll be curious to see how often we run into the issue described there. I also really like the idea highlighted in the blog post of adding async sugar to function closure types as part of expanding the support for async closures, e.g.: where F: async FnOnce() -> T // rather than where F: FnOnce() -> impl Future<Output=T> Personally, the lack of good support for async in closures remains one of my only issues with async, just because we often write code in a more "functional" style, and whenever we're dealing with complex async stuff we often wind up having to drop out of that.