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

31–40 of 90 posts

Re: Async/Await is finally back in Zig

#31

Post by Calavar »

jayd16 wrote: post #27
Calavar wrote: post #15

Earlier quoted context omitted.

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.

Const is similar, now that you mention it.

Const is the reverse.

Constness is infectious down the stack (the callee of a const function must be const) while asyncness is infectious up the stack (the caller of an async function must be async). So you can gradually add constness to subsections of a codebase while refactoring, only touching those local parts of the codebase. As opposed to async, where adding a single call to an async function requires you to touch all functions back up to main

Re: Async/Await is finally back in Zig

#32

Post by rr808 »

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…

With Java 25 virtual threads, async definitely is no longer required and I hope it dies a slow and painful death. We have projects at work that have never more than 3 concurrent users that use rxjava and are a nightmare to work on.

Re: Async/Await is finally back in Zig

#33

Post by iroddis »

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.

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 “concurrency”, but the complaint that async is a poison pill is valid, because the use of async fundamentally changes the execution model to co-operative multitasking, with possible runtime issues.

If a language chooses async, I wish they’d just bite the bullet and make it obvious that it’s a different language / execution model than the sync version.

Re: Async/Await is finally back in Zig

#34

Post by dns_snek »

luke5441 wrote: post #21
rafaelmn wrote: post #11

Earlier quoted context omitted.

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.

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

Re: Async/Await is finally back in Zig

#35

Post by antihero »

troupo wrote: post #22
lukaslalinsky wrote: post #16

Earlier quoted context omitted.

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…

> The alternatives are callbacks No. The alternative is lightweight/green threads and actors. The thing with await is that it can be retrofitted onto existing languages and runtimes with relatively little effort. That is, it's significantly less effort than retrofitting an actual honest-to-god proper actor system a la Erlang.

Isn’t await often just sugar around the underlying implementation be that greenthreads, epoll, picoev, etc?

Re: Async/Await is finally back in Zig

#36

Post by api »

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…

I think it’s a terrible complexity multiplying workaround for the fact that we can’t fix our ancient 1970s OS APIs. Threads should be incredibly cheap. I should be able to launch them by the tens of millions, kill them at will, and this should be no more costly than goroutines.

(All modern OSes in common use are 1970s vintage under the hood. All Unix is Bell Labs Unix with some modernization and veneer, and NT is VMS with POSIX bolted on later.)

Go does this by shipping a mini VM in every binary that implements M:N thread pooling fibers in user space. The fact that Go has to do this is also a workaround for OS APIs that date back to before disco was king, but at least the programmer doesn’t have to constantly wrestle with it.

Our whole field suffers greatly from the fact that we cannot alter the foundation.

BTW I use Rust async right now pretty heavily. It strikes me as about as good as you can do to realize this nightmare in a systems language that does not ship a fat runtime like Go, but having to actually see the word “async” still makes me sad.

Re: Async/Await is finally back in Zig

#37

Post by matheusmoreira »

troupo wrote: post #22
lukaslalinsky wrote: post #16

Earlier quoted context omitted.

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…

> The alternatives are callbacks No. The alternative is lightweight/green threads and actors. The thing with await is that it can be retrofitted onto existing languages and runtimes with relatively little effort. That is, it's significantly less effort than retrofitting an actual honest-to-god proper actor system a la Erlang.

> The alternative is lightweight/green threads and actors.

How lightweight should threads be to support high scale multitasking?

Writing my own language, capturing stack frames in continuations resulted in figures like 200-500 bytes. Grows with deeply nested code, of course, but surely this could be optimized...

https://www.erlang.org/docs/21/efficiency_guide/processes.ht...

This document says Erlang processes use 309 words which is in the same ballpark.

Re: Async/Await is finally back in Zig

#38

Post by devnull3 »

All the stunts in async/await or goroutines in go stem from the fact that there is no support for something lighter than posix threads in kernel.

Shouldn't the OS kernel innovate in this area instead of different languages in userland attempting to solve it?

Re: Async/Await is finally back in Zig

#39

Post by bcrosby95 »

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.

This is like saying knowing if you're dealing with NEAR pointers or FAR pointers is extremely relevant. I reject the premise - a model that forces me to think about these things is a degenerate model.

Re: Async/Await is finally back in Zig

#40

Post by kibwen »

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.

Same. Colored functions are just effect systems, which are extremely useful.

Javascript's async as of ten years ago just happened to be an especially annoying implementation of a specific effect.

Post reply on HN