←back to thread

Async/Await is finally back in Zig

(charlesfonseca.substack.com)
39 points barddoo | 1 comments | | HN request time: 0s | source
Show context
ajross ◴[] No.45782414[source]
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 debugging inside out code is likewise really high, even if the top-level expression of the loop generator or whatever is clean.

And it's all for, what? A little memory for thread stacks (most of which ends up being a wash because of all the async contexts being tossed around anyway -- those are still stacks and still big!)? Some top-end performance for people chasing C10k numbers in a world that has scaled into datacenters for a decade anyway?

Not worth it. IMHO it's time to put this to bed.

[1] No one in that thread or post has a good summary, but it's "Rust futures consume wakeup events from fair locks that only emit one event, so can deadlock if they aren't currently being selected and will end up waiting for some other event before doing so."

replies(5): >>45782432 #>>45782502 #>>45782558 #>>45782647 #>>45782786 #
jayd16 ◴[] No.45782502[source]
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.

replies(8): >>45782525 #>>45782537 #>>45782580 #>>45782601 #>>45782790 #>>45782846 #>>45782853 #>>45782877 #
pton_xd ◴[] No.45782525[source]
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.
replies(1): >>45782549 #
rafaelmn ◴[] No.45782549[source]
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.

replies(3): >>45782668 #>>45782941 #>>45782999 #
1. ojosilva ◴[] No.45782941{3}[source]
The problem with Node is that the async decision is in the hand of the leaf node, which bubbles up to the parent where my code sits. Async/await is nice and a goal in most modern Node, but there are codebases (old and new) where async/await is just not an option for many reasons.

Node dictates that when faced with an async function the result is that I must either implement async myself so I can do await or go into callback rabbit holes by doing .then(). If the function author is nice, they will give me both async and sync versions: readFile() and readFileSync(). But that sucks.

The alternative would be that 1) the decision to go async were mine; 2) the language supports my decision with syntax/semantics.

Ie. if I call the one and only fs.readFile() and want to block I would then do

       sync fs.readFile()
Node would take care of performing a nice synchronous call that is beneficial to its event-loop logic and callback pyramid. End of the story. And not some JS an implementation such as deasync [1] but in core Node.

1. https://www.npmjs.com/package/deasync