I am not saying threads are the model for all programming problems. For example a dependency graph like an excel spreadsheet can be analyzed and parallelized.
replyBut as you observed, async/await fails to express concurrency any better. It’s also a thread, it’s just a worse implementation.
That’s incorrect. Even when expressed suboptimally, it still tends to result in overall higher throughput and consistently lower latency (work stealing executors specifically). And when you’re in this world, you can always do an optimization pass to better express the concurrency. If you’ve not written it async to start with, then you’re boned and have no easy escape hatch to optimize with.
replyWhy can’t you do the same optimization? Are you maxing out you OS system resources on thread overhead?
replyOS thread overhead can be pretty substantial. Starting new threads on Windows is especially expensive.
reply> threads are inherently and inescapably too heavy weight to express concurrency in an efficient way
replyYour premise is wrong. There are many counterexamples to this.
Can you explain more ? I always heard this.
replyThe most promiment example is probably Go with its goroutines, but there are so many more. You can easily spawn tens of thousands of goroutines, with low overhead and great performance.
replyGoroutines/"fibers"/"green threads" are usually scheduled by the runtime system across a small pool of actual OS threads.
reply