Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async/Await is finally back in Zig

charlesfonseca.substack.com

Post reply on HN
Print view View original

11–20 of 90 posts

Re: Async/Await is finally back in Zig

#11

Post by rafaelmn »

pton_xd wrote: post #9
jayd16 wrote: post #7

Earlier quoted context omitted.

I really wish people would get over the coloring meme. Knowing if a function will yield the thread is actually extremely relevant knowledge you want available.

Look at the node.js APIs: readFile, readFileSync, writeFile, writeFileSync ... and on and on. If that's not a meme then I don't know what is.

And the alternative without async-await is ? blocking the event loop or the callback pyramid.

Node is one place where async-await has zero counter arguments and every alternative is strictly worse.

Re: Async/Await is finally back in Zig

#12

Post by the__alchemist »

ajross wrote: post #3

Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debug…

Concur. I build my own tools in rust when I have to just to avoid it. It is splitting rust into 2 ecosystems, and I wish it didn't exist because it's a big compatibility barrier. We should be moving towards fewer of these; not more. Make code and applications easier to interop; Async makes it more difficult.

Re: Async/Await is finally back in Zig

#13

Post by dilawar »

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.

Re: Async/Await is finally back in Zig

#14

Post by bmacho »

jayd16 wrote: post #7
ajross wrote: post #3

Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debug…

I really wish people would get over the coloring meme. Knowing if a function will yield the thread is actually extremely relevant knowledge you want available.

Funny you mention this.

Zig's colorless async was purely solving the unergonomic calling convention, at the cost of knowing if a function is async or not (compiler decides, does not give any hints and if you get it wrong then that's UB).

Arguably the main problem with async is that it is unergonomic. You always have to act like there were 2 types of functions, while, in practice, these 2 types are almost always self-evident and you can treat sync and async functions the same.

Re: Async/Await is finally back in Zig

#15

Post by Calavar »

jayd16 wrote: post #7
ajross wrote: post #3

Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debug…

I really wish people would get over the coloring meme. Knowing if a function will yield the thread is actually extremely relevant knowledge you want available.

Of course it's useful, that's why function modifiers like 'const' or 'virtual' (thinking from a C++ perspective) are widely seen as useful, but making one function virtual doesn't force you to propagate that all the way up the call tree.

Re: Async/Await is finally back in Zig

#16

Post by lukaslalinsky »

dilawar wrote: post #13

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 l…

https://en.wikipedia.org/wiki/C10k_problem

Because when you require 1 thread per 1 connection, you have trouble getting to thousands of active connections and people want to scale way beyond that. System threads have overhead that makes them impractical for this use case. The alternatives are callbacks, which everybody hates and for a good reason. Then you have callbacks wrapped by Futures/Promises. And then you have some form of coroutines.

Keeping in mind that what Zig is introducing is not what languages call async/await. It's more like the I/O abstraction inside Java, where you can use the same APIs with platform threads and virtual threads, but in Zig, you will need to pass the io parameter around, in Java, it's done in the background.

Re: Async/Await is finally back in Zig

#17

Post by echelon »

the__alchemist wrote: post #12
ajross wrote: post #3

Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debug…

Concur. I build my own tools in rust when I have to just to avoid it. It is splitting rust into 2 ecosystems, and I wish it didn't exist because it's a big compatibility barrier. We should be moving towards fewer of these; not more. Make code and applications easier to interop; Async makes it more difficult.

I can't stand this aversion to async/await. It's not a big deal.

I don't understand why async code is being treated as dangerous or as rocket science. You still maintain complete control, and it's straightforward.

Now that we know about the "futurelock" issue, it will be addressed.

I'm sure Rust and the cargo/crates ecosystem will even grow the ability to mark crates as using async so if you really care to avoid them in your search or blow up at compile time upon import, you can. I've been asking for that feature for unsafe code and transitive dependency depth limits.

Re: Async/Await is finally back in Zig

#18

Post by efdee »

ajross wrote: post #5
amelius wrote: post #4

Earlier quoted context omitted.

What is wrong about C++ exceptions?

"Nothing", in principle. But they're bug factories in practice. It's really easy to throw "past" cleanup code in a language where manual resource management remains the norm. It's not that they can't be used productively. It's that they probably do more harm than good on balance. And I think async mania is getting there. It was a revelation when node showed it to us 15 years ago. But it's evolved in bad directions, I…

C# had async/await long before Javascript/node. Not that big a revelation ;-)

Re: Async/Await is finally back in Zig

#19

Post by csande17 »

ajross wrote: post #3

Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debug…

Your comment is downvoted as I write this, but I kind of think Zig's new design agrees with you. It uses the terms "async" and "await", but the API design looks more similar to traditional threading (like Rust's thread::spawn and join() APIs). With the fun distinction that you can choose whether your program uses actual threads, or coroutines, or just runs everything synchronously without changing any of your code.
Post reply on HN