zlacker

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+(OP)
I disagree. I've got several programs with a async select based main loop and others with threads, and the former are easier to reason about in my opinion. Threads hide effects.

However, Tokio tries to be the best of both threads and async and sometimes ends up being the worst of both when Sync/Send/etc creep into function signatures.

>>baq+(OP)
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.

>>baq+(OP)
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.

>>the_mi+E5
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+s7
Sure, but that’s not really an argument for or against async but for or against different runtime policies.

>>the_mi+Ld
What good are "runtime policies" if you're in a single thread that you can't interrupt (which is what async is)?

>>ameliu+aT
Async is not really that in Rust. While it's true that a singular poll cannot be preempted, things like task::spawn schedule that on a multi threaded executor. So a lot of cases behave just like threads except you await them from somewhere else.