The classic use case for async was applications with extreme I/O intensity, like high-end database engines. If designed correctly it is qualitatively higher performance than classic multithreading. This is the origin of async style.
Those large performance gains do not actually come from async style per se, which is where people become confused.
What proper async style allows that multithreading does not is that you can design and implement sophisticated bespoke I/O and execution schedulers for your application. Almost all the performance gains are derived from the quality of the custom scheduling.
If you delegate scheduling to a runtime, it almost completely defeats the point of writing code in async style.
> The classic use case for async was applications with extreme I/O intensity, like high-end database engines. If designed correctly it is qualitatively higher performance than classic multithreading.
FWIW, I'm not aware of any high end database engines that make significant use of async code on their performance paths. They manage concurrent state with event loops, state machines, and callbacks. Those techniques, while crufty and too old to be cool, are themselves significantly faster than async.
Async code (which is isomorphic to process-managed green threads) really isn't fast. It's just that OS thread switching is slow.
Those large performance gains do not actually come from async style per se, which is where people become confused.
What proper async style allows that multithreading does not is that you can design and implement sophisticated bespoke I/O and execution schedulers for your application. Almost all the performance gains are derived from the quality of the custom scheduling.
If you delegate scheduling to a runtime, it almost completely defeats the point of writing code in async style.