←back to thread

Async/Await is finally back in Zig

(charlesfonseca.substack.com)
39 points barddoo | 2 comments | 01 Nov 25 14:14 UTC | HN request time: 0s | source
Show context
dilawar ◴[01 Nov 25 15:44 UTC] No.45782574[source]▶
Someone has historical insights into why async/await seems to have taken over the world?

I often write Rust and I don't find it very attractive, but so many good projects seem to advertise it as a "killer feature". Diesel.rs doesn't have async, and they claim that perf improvement may not be worth it (https://users.rust-lang.org/t/why-use-diesel-when-its-not-as...).

For a single threaded JS program, async makes a lot of sense. I can't imagine any alternative pattern to get concurrency so cleanly.

replies(8): >>45782621 #>>45782683 #>>45782771 #>>45782778 #>>45782809 #>>45782885 #>>45782984 #>>45784113 #
1. jandrewrogers ◴[01 Nov 25 18:35 UTC] No.45784113[source]▶
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.

replies(1): >>45784265 #
2. ajross ◴[01 Nov 25 18:52 UTC] No.45784265[source]▶
> 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.