[hsjsbeebue]

What is the language agnostic answer to the same question?

I imagine something to do with memory usage or avoiding thread or thread pool starvation issues. Maybe performance too?

[toast0]

I don't have a lot of experience with async/await at high numbers of tasks, but I've run Erlang with millions of processes. It's a lot easier to run millions of Erlang processes on one machine than to run a million OS threads. I suspect async tasks would be similar; an OS thread needs its own stack, and that's going to use at least a page of memory, but often much more. Otoh, an async task or green thread might be able to use less.

If you're running real OS threads, I think task switching is going to be real context switches, which might mean spectre mitigations clear your cpu caches, but task switching can avoid that.

You may end up with more system calls with OS threads, because your runtime might be able to aggregate things a bit (blocking reads become kqueue/epoll/select, but maybe that's actually a wash, because you do still need a read call when the FD is ready, and real blocking only makes a single call)

[lmm]

IMO the biggest reason to avoid threads is simply that it's ~impossible to write safe code using threads (e.g. without race conditions). Arguably with Rust's ownership system that's less true there than in other languages.

[treflop]

Asynchronous code has race conditions and synchronization issues too.

I pray for all the code written by people who think they didn’t need to learn about synchronization because they wrote asynchronous code.

And unfortunately I’ve come across and had to fix asynchronous code with race conditions.

You cannot escape learning about synchronization. Writing race-condition-free code is not hard.

What is actually hard is writing fast lock-free routines, but that’s more a parallelism problem that affects both threaded and asynchronous code. And most people will never need to reach that level of code optimization for their work.

[kaba0]

Async-await is about concurrency, not parallelism. It can work in both a single-threaded and multi-threaded context, the latter exposing all the typical failure modes of multi-threaded code.

Also, Rust’s ownership model only prevents data races, that’s only the tip of the iceberg of race conditions, and I don’t think that any general model makes it possible to statically determine that any given multithreaded code is safe. Nonetheless, that’s the only way to speed up most kind of code, so possibly the benefits outweigh the cost in many cases.

[logicchains]

You can write safe code using threads if you enforce that the only way threads can communicate is by sending messages to each other (via copying, not pointers). This is what Erlang does.

[lelanthran]

> IMO the biggest reason to avoid threads is simply that it's ~impossible to write safe code using threads (e.g. without race conditions).

Javascript has race conditions too, even with no threads involved.