Async vs Threads

You're doing nothing wrong other than using async. You'll only become an async fan once you write a program that does no interesting CPU work, just a lot of I/O - because async is great for the case where the computer spends most of its time waiting around for multiple (or possibly even quite a lot more than that) I/O requests to complete, then does a bit of CPU work on completion of each in order to decide what I/O to do next. Then repeat forever.This stuff is always

Async is superior. I have done processes with locks in shared memory. I have done threads. But I predict Async will slowly start to take over. Processes are not suitable for working on shared data. Threads frequently yield race conditions and deadlocks even for experienced coders. But Async doesn't have any of these issues. So why isn't it more popular? For two reasons:1) it completely breaks the functional programming model that we all learned as toddlers (instead of call A and the

Async is, in many situations, better than traditional threads.Threads are a resource hog. They take a lot of system resources, and so you usually want to have as few of them as possible. This is a problem for applications that could, in theory, support thousands of concurrent connections, if not more. With a basic thread-based model, you need 1 thread per connection, and if you have long-lived connections with infrequent traffic, those threads mostly do nothing but consume precious system re

Threads are for when you COMPUTE a lot, while async/await are for when you WAIT a lot.

Async is great for dealing with I/O but it forgets that the CPU is a resource too.

It's... faster for IO bound workloads? That's literally the whole point of async

Threads are much much slower than async/await.

I find async/await easier to reason about than threads for anything more involved than the 1 request per thread web server use case. This is because you avoid bringing in the abstraction of threads (or green threads) and their communication with one another. You trade syntactical complexity (what color is your function, etc), for semantic complexity (threads, channels, thread safety, lock races).

The article actually said "concurrency." In the case of the article, it's being oversold because it's not that much better than the old one thread per request model. Cross-request interactions are rare, so you're more or less writing the same code, only with async, you have to be careful not to accidentally do something CPU-intensive for 50ms, and if your runtime supports multiple cores (so not Ruby or Python), you still have to be careful with race conditions and

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 ...