←back to thread

Async/Await is finally back in Zig

(charlesfonseca.substack.com)
39 points barddoo | 1 comments | | HN request time: 0.001s | source
Show context
dilawar ◴[] 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. devjab ◴[] No.45782984[source]
Microsoft did some research on it 15-20 years ago for .NET which showed that sync doesn't scale for I/O workloads. The rest of the world sort of "knew" at this point, and all the callback and statemachine hell which came before was also leading the world toward async/await but the Microsoft research kind of formed the foundation for "universal" acceptance. It's not just for single threaded JS programs, you almost never want to tie up your threads even when you can have several of them because it's expensive in memory. As you'll likely see in this thread, some lower level programmers will mention that they prefer to build stackful coroutines themselves. Obviously that is not something Microsoft wanted people to have to do with C#, but it's a thing people do in c/c++ and similar (probably not with C#), and if you're lucky, you can even work in a place that doesn't turn it into the "hell" part.

I can't say why Diesel.rs doesn't need async, and I would like to point out that I know very little about Diesel.rs beyond the fact that it has to do with databases. It would seem strange that, anything, working with databases which an I/O heavy workload would not massively benefit from async though.