←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. robmccoll ◴[01 Nov 25 15:59 UTC] No.45782683[source]▶
In single threaded scripting languages, it has arisen as a way to allow overlapping computation with communication without having to introduce multi threading and dealing with the fact that memory management and existing code in the language aren't thread-safe. In other languages it seems to be used as a away to achieve green threading with an opt-in runtime written as a library within the language rather than doing something like Go where the language and built-in runtime manage scheduling go routines onto OS threads. Personally I like Go's approach. Async / await seems like achieving a similar thing with way more complexity. Most of the time I want an emulation of synchronous behavior. I'd rather be explicit around when I want something to go run on it's own.
replies(1): >>45783776 #
2. fmajid ◴[01 Nov 25 17:57 UTC] No.45783776[source]▶
Agreed. Async I/O is something where letting the runtime keep track of it for you doesn't incur any more overhead, unlike garbage collection, and that makes for a much more natural programming pseudo-synchronous.