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

41–50 of 90 posts

Re: Async/Await is finally back in Zig

#41

Post by ajross »

efdee wrote: post #18
ajross wrote: post #5

Earlier quoted context omitted.

"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 ;-)

.NET wasn't the first either. Lisps were doing continuations in the 70's.

But "invented" and "revealed" are different verbs for a reason. The release of node.js and it's pervasively async architecture changed the way a lot of people thought about how to write code. For the better in a few ways. But the resulting attempt to shoe-horn the paradigm into legacy and emerging environments that demanded it live in a shared ecosystem with traditional "blocking" primitives and imperative paradigms has been a mess.

Re: Async/Await is finally back in Zig

#42

Post by luke5441 »

jayd16 wrote: post #29
luke5441 wrote: post #21

Earlier quoted context omitted.

They could have added threads to Node as well? Granted, it would have been a lot of difficult work.

You mean like with web workers or something?

With a shared interpreter/process state, like Python, Java, C, C++, ...

Node is not a web page, so no reason to limit it to the same patterns.

Then, the next issue would be thread safety. But that could be treated as a separate problem.

Re: Async/Await is finally back in Zig

#43

Post by valcron1000 »

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.

> Knowing if a function will yield the thread is actually extremely relevant knowledge you want available.

When is this relevant beyond pleasing the compiler/runtime? I work in C# and JS and I could not care less. Give me proper green threads and don't bother with async.

Re: Async/Await is finally back in Zig

#44

Post by felipellrocha »

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…

Being fully multithreaded comes with significant overhead, while browsers essentially proved how much unreasonable performance you can get out of a single cpu using async because of javascript’s async model.

It is hard to describe just how much more can be done on a single thread with just async.

Re: Async/Await is finally back in Zig

#45

Post by jayd16 »

iroddis wrote: post #33
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.

Except function colouring is a symptom of two languages masquerading as one. You have to choose async or sync. Mixing them is dangerous. It’s not possible to call an async function from sync. Calling sync functions from async code runs the risk of holding the run lock for extended periods of time and losing the benefit of async in the first place. I don’t have anything against async, I see the value of event-oriented…

I think this analogy is too extreme. That said, modern languages should probably consider the main function/threading context default to async.

Calling sync code from async is fine in and of itself, but once you're in a problem space where you care about async, you probably also care about task starvation. So naively, you might try to throw yeilds around the code base.

And your conclusion is you want the language to be explicit when you're async....so function coloring, then?

Re: Async/Await is finally back in Zig

#46

Post by luke5441 »

dns_snek wrote: post #34
luke5441 wrote: post #21

Earlier quoted context omitted.

They could have added threads to Node as well? Granted, it would have been a lot of difficult work.

Losing threads and moving to the async I/O model was the motivation behind Node in the first place. https://nodejs.org/en/about

If you use async I/O you can just use the Chrome JavaScript runtime as-is. I would claim it was the only low-effort model available to them and therefore not motivation.

The motivation for node was that users wanted to use JavaScript on the server.

Re: Async/Await is finally back in Zig

#47

Post by amelius »

KerrAvon wrote: post #6
amelius wrote: post #4

Earlier quoted context omitted.

What is wrong about C++ exceptions?

For one thing, they’re expensive and viral. “Zero overhead” implementations don’t take into account the need for unwind tables. For every function/method that might be thrown across. They’re disabled in a lot of production environments for this reason.

But if you explicitly handle exceptions using IF statements then that's overhead too, right?

Re: Async/Await is finally back in Zig

#48

Post by ojosilva »

rafaelmn wrote: post #11
pton_xd wrote: post #9

Earlier quoted context omitted.

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.

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

Re: Async/Await is finally back in Zig

#49

Post by jayd16 »

valcron1000 wrote: post #43
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.

> Knowing if a function will yield the thread is actually extremely relevant knowledge you want available. When is this relevant beyond pleasing the compiler/runtime? I work in C# and JS and I could not care less. Give me proper green threads and don't bother with async.

Knowing when execution will yield is useful when you want to hold onto a thread. If you run your GUI related async tasks on the GUI thread you don't have to worry about locks or multi threaded data structures. Only a single GUI operation will happen at a time.

If yields are implicit, you don't have enough control to really pull that off.

Maybe it's possible but I haven't seen a popular green threaded UI framework that let's you run tasks in background threads implicitly. If I need to call a bunch of code to explicitly parcel background work, that just ends up being async/await with less sugar.

Re: Async/Await is finally back in Zig

#50

Post by amelius »

jandrewrogers wrote: post #26
amelius wrote: post #4

Earlier quoted context omitted.

What is wrong about C++ exceptions?

There are cases in systems-y code where it is not safe to unwind the stack in the ordinary way and it is difficult to contain the side-effects. These can be non-obvious and subtle edge cases that are often difficult to see and tricky to handle correctly. C++ today is primarily used in code contexts where these kinds of issues can occur. This is why it is a standard practice to disable exceptions at build time i.e. -f…

But you can implement exceptions by using the same IF statement approach you would use for manual error handling. No need for unwinding tables and such if that optimization is a bridge too far for your specific target platform.
Post reply on HN