async-trait VS monadless

As of today, async functions in traits are not natively supported by Rust. Fortunately, David Tolnay got our back covered (one more time): we can use the async-trait crate.

You might want to check out https://github.com/dtolnay/async-trait to be able to declare async functions in a trait.

Also async-trait (GitHub), dtolnay has done some great work!

Does async-trait count as a trick or hack? It's not my hack, but it's a workaround/hack that I use every single day.

This macro goes a very long way toward solving the problem: https://github.com/dtolnay/async-trait

I'm still learning async to I cannot answer all the questions. First of all, I use this -> https://github.com/dtolnay/async-trait to take care of the async-inside-traits mess.

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).