zlacker

>>jmakov+(OP)
I think the better way to think about async Rust is to use it when it's beneficial to developer productivity and to avoid it when not. There are quite a few situations where it makes the code easier compared to alternatives you could come up with.

I don't think for a second that async Rust should be picked for performance reasons.

You get a feeling for what is a good use of async and bad use of async relatively easily these days as the ecosystem is maturing.

>>the_mi+87
What arguments are there for async if not performance? Threads/fibers/gofuncs/actors/... are easier to reason about. Async is super helpful to avoid overhead of thousands of threads, but makes just about everything else harder.

>>baq+88
Async makes awaiting things much easier than other primitives in the language. So for instance if you both need to wait for stuff to happen on a socket or some event happening, async select makes that super easy.

You can also keep async relatively local to a function that does these things and is itself blocking otherwise.

>>the_mi+Md
Yes, async is easier, but granularity of performance is a real downside. The CPU is a resource too, and needs to be managed more carefully than async can do. There's a reason why people stopped using cooperative multitasking like in Windows 3.1 ...

>>ameliu+Af
Sure, but that’s not really an argument for or against async but for or against different runtime policies.