The problem is that in Rust the main way of doing async/await (Tokio) is multithreaded by default. So you get all the problems of multithreading, and additionally all the problems with async/await. The discourse would be very different if the default choice of executor would have been thread-local.
Is this default really that big of a problem? Most people running Tokio are going to be running it on multicore hardware, and they'll get some additional throughput for free. If they're sufficiently resource constrained to the degree that they realize that a single thread is a better fit for their domain, they'll Google it and realize you can use Tokio's single-threaded runtime.
To be clear: it is a one-line change to make Tokio use the current (single) thread.
Those Send + 'static bounds have really big impact. Multithread is definitely not just "additional throughput for free", nor is the change between single to multi just one line of code.
Yes, this is a big problem in my mind and something I mentioned in another comment. Not that multi-threaded async/await is wrong, but the conflation of two methods of concurrency causes a lot of problems you don't see in single-threaded event-loops archs.
In fact it makes me feel like the other thread talking about how async/await in rust was mainly forced on the community to capture js devs seems a bit unlikely as the only thing similar between the two are the spelling of the keywords.
