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
I use (custom-made) actors and (Tokio) channels a lot, and I build them with async.

I do make separate threads when necessary (e.g. to encapsulate blocking I/O).

It can approximate an Erlang experience.

But with a lot more boilerplate and lack of good actor library patterns.