Is async in Rust really this bad? Last time I used Rust was before that existed. I know it's a pain in Python because they bolted it on way after, but in JS it's a breeze because everything standardized on promises early.
If your reference is JS or C#, then Rust's async has more friction and annoying details. But Rust is generally harder due to being low-level and picky about memory management and thread-safety details. In a way it's a compliment that Rust's usability even gets compared to GC languages.
If you compare it to hand-rolling state machines in C, or even callbacks in pre-async Rust, then it's an amazing simplification and a very sweet syntax sugar. Especially when you want async code composable, supporting control flow and cancellation.
If you compare it to naive sync Rust while ignoring the extra capabilities that async adds, then async is more complicated and less feature-complete (Streams have more moving parts than Iterators, generic async closures have trickier syntax than generic sync closures, there are scoped threads but no scoped multi-threaded futures, etc). IMHO the difference isn't large and it's reasonable for what you get.
There's also a view that async/await syntax is fundamentally misguided and shouldn't exist at all. From Rust's perspective that's an agree-to-disagree. Rust tried having green threads first (before 1.0) and decided it was too intrusive and magic for a low-level systems language. Rust tried to make do with just threads, callbacks and macros, but it didn't work well either (user code can't make futures compose and optimize as well without compiler's help, especially when you want borrow checker to work with it).