3 ms·
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
by baq 3y ago
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.
- bryanlarsen 3y agoI 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.
- the_mitsuhiko 3y agoAsync 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.
- amelius 3y agoYes, 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 ...
- the_mitsuhiko 3y agoSure, but that’s not really an argument for or against async but for or against different runtime policies.
- amelius 3y agoWhat good are "runtime policies" if you're in a single thread that you can't interrupt (which is what async is)?
- the_mitsuhiko 3y agoAsync 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.
- sshine 3y agoI 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.