It's been 7 months since I didn't write async code so it will be difficult for me to give u a proper answer but I'll try.
the learning curve, the cryptic lifetime compiler errors, the lack of async trait, no async Fn but async block instead, differents libraries using different runtimes, spending hours to compile a trivial code, the box pin Dyn boxfuture thingy, the compile time, issues with analyzer etc.
But most important the fact that you couldn't write code just as you would in sync rust.
Most of the features of sync rust don't compose well with async rust. At every step, async rust feels like it's a proof of concept, an half baked feature that should never had reached stable in that state.
Rushing it was a mistake to me. You shouldn't need a PhD in async await to use it properly. It should feel like writing normal rust code. Unfortunately, it's not.
Async Rust is still considered MVP, perhaps surprisingly.
> Most of the features of sync rust don't compose well with async rust.
There are two parts to that. Missing features that are required to compose the features (GATs are a good example), and bugs/incoherencies/just inconveniences.
The latter will eventually get fixed hopefully, although some of them are really hard the recent work on a-mir-formality is going to help this. The former are probably going to be solved too, but it'll be harder and perhaps require more time. As far as I can tell, nothing is impossible by the design of the async/await MVP (it was designed for that, so this is not really surprising).
FWIW, both happen in non-async code too. It's just that async code takes the type system to its extreme, and so it has more surprises.
I hope you are right (about the MVP being flexible enough to be fixed in further releases)
the problem is that the ecosystem is already built on top of multiples workarounds to overcome the problem of async rust (a.k.a the "higher level libraries"), it will be for sure a challenge to fix all the legacy code already written with the current MVP.
I don't know how they're gonna do that. that's also a reason why I don't want to have dependencies on things that may be broken in a couple of year.
I hope they will never do the same mistake. It's better to keep a half baked feature in nightly for a decade than pushing it to stable and have to deal with it forever.
the learning curve, the cryptic lifetime compiler errors, the lack of async trait, no async Fn but async block instead, differents libraries using different runtimes, spending hours to compile a trivial code, the box pin Dyn boxfuture thingy, the compile time, issues with analyzer etc.
But most important the fact that you couldn't write code just as you would in sync rust. Most of the features of sync rust don't compose well with async rust. At every step, async rust feels like it's a proof of concept, an half baked feature that should never had reached stable in that state.
Rushing it was a mistake to me. You shouldn't need a PhD in async await to use it properly. It should feel like writing normal rust code. Unfortunately, it's not.