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

Zig's new plan for asynchronous programs

lwn.net

Post reply on HN
Print view View original

151–160 of 274 posts

Re: Zig's new plan for asynchronous programs

#151

Post by zamalek »

algesten wrote: post #120
zamalek wrote: post #102

Earlier quoted context omitted.

It's sans-io at the language level, I like the concept. So I did a bit of research into how this works in Zig under the hood, in terms of compilation. First things first, Zig does compile async fns to a state machine: https://github.com/ziglang/zig/issues/23446 The compiler decides at compile time which color to compile the function as (potentially both). That's a neat idea, but... https://github.com/ziglang/zig/issu…

I wouldn't define it as Sans-IO if you take an IO argument and block/wait on reading/writing, whether that be via threads or an event loop. Sans-IO the IO is _outside_ completely. No read/write at all.

Oof, you're completely right. I'm not sure where I got that wire crossed.

Re: Zig's new plan for asynchronous programs

#152

Post by davidee »

thefaux wrote: post #79

This design seems very similar to async in scala except that in scala the execution context is an implicit parameter rather than an explicit parameter. I did not find this api to be significantly better for many use cases than writing threads and communicating over a concurrent queue. There were significant downsides as well because the program behavior was highly dependent on the execution context. It led to spooky…

https://www.scala-lang.org/api/current/scala/concurrent/Exec... in case anyone is interested.

Re: Zig's new plan for asynchronous programs

#153

Post by simonask »

messe wrote: post #38
rowanG077 wrote: post #31

Earlier quoted context omitted.

Where do you think the Io parameter comes from? If you change some function to do something async and now suddenly you require an Io instance. I don't see the difference between having to modify the call tree to be async vs modifying the call tree to pass in an Io token.

Synchronous Io also uses the Io instance now. The coloring is no longer "is it async?" it's "does it perform Io"? This allows library authors to write their code in a manner that's agnostic to the Io runtime the user chooses, synchronous, threaded, evented with stackful coroutines, evented with stackless coroutines.

The interesting question was always “does it perform IO”.

Re: Zig's new plan for asynchronous programs

#155

Post by zelphirkalt »

jcranmer wrote: post #51
flohofwoe wrote: post #34

Earlier quoted context omitted.

If calling the same function with a different argument would be considered 'function coloring', every function in a program is 'colored' and the word loses its meaning ;) Zig actually also had solved the coloring problem in the old and abandondend async-await solution because the compiler simply stamped out a sync- or async-version of the same function based on the calling context (this works because everything is a…

> If calling the same function with a different argument would be considered 'function coloring', than every function in a program is 'colored' and the word loses its meaning ;) I mean, the concept of "function coloring" in the first place is itself an artificial distinction invented to complain about the incongruent methods of dealing with "do I/O immediately" versus "tell me when the I/O is done"--two methods of I/…

Function coloring is the issue, that arises in practice, which is why people discuss, whether some approach solves it or does not.

Why do you think it automatically follows, that with an async I/O you are going to have a streaming API? An async I/O can just like the sync I/O return a whole complete result, only that you are not waiting for that to happen, but the called async procedure will call you back once the result is calculated. I think a streaming API requires additional implementation effort, not merely async.

Re: Zig's new plan for asynchronous programs

#156

Post by eikenberry »

woodruffw wrote: post #132
eikenberry wrote: post #122

Earlier quoted context omitted.

Function coloring is specifically about requiring syntax for a function, eg. the async keyword. So if you want an async and non-async function you need to write both in code. If you pass the "coloring" as an argument you avoid the need for extra syntax and multiple function definitions and therefor the function has no color. You can solve this in various ways with various tradeoffs but as long as there is a single fu…

> Function coloring is specifically about requiring syntax for a function, eg. the async keyword. Someone should tell the inventor of the phrase, because they don't mention the async keyword at all[1]. As-written, function coloring is about callbacks (since that's semantic mechanism that JavaScript happens to pick for their asynchronous model). Function coloring is just an informal way to describe encoding a function…

They specifically called it out as a syntactical issue, where the issue was based around the requirement to have the 'red' or 'blue' keyword. The section on "2. The way you call a function depends on its color." makes this pretty explicit...

    2. The way you call a function depends on its color.

    Imagine a “blue call” syntax and a “red call” syntax. Something like:

    doSomethingAzure()blue;
    doSomethingCarnelian()red;

    When calling a function, you need to use the call that corresponds to its color.

Re: Zig's new plan for asynchronous programs

#157

Post by zarzavat »

flohofwoe wrote: post #34
woodruffw wrote: post #22

I think this design is very reasonable. However, I find Zig's explanation of it pretty confusing: they've taken pains to emphasize that it solves the function coloring problem, which it doesn't: it pushes I/O into an effect type, which essentially behaves as a token that callers need to retain. This is a form of coloring, albeit one that's much more ergonomic. (To my understanding this is pretty similar to how Go sol…

If calling the same function with a different argument would be considered 'function coloring', every function in a program is 'colored' and the word loses its meaning ;) Zig actually also had solved the coloring problem in the old and abandondend async-await solution because the compiler simply stamped out a sync- or async-version of the same function based on the calling context (this works because everything is a…

In that case JS is not colored either because an async function is simply a normal function that returns a Promise.

As far as I understand, coloring refers to async and sync functions having the same calling syntax and interface, I.e.

    b = readFileAsync(p)
    b = readFileSync(p)
share the same calling syntax. Whereas

    b = await readFileAsync(p)
    readFileAsync(p).then(b => ...)
    
    b = readFileSync(b)
are different.

If you have to call async functions with a different syntax or interface, then it's colored.

Re: Zig's new plan for asynchronous programs

#158

Post by ivanjermakov »

idle_zealot wrote: post #154

Passing io into things over and over seems annoying. Like, you can use io to get a File instance, then you need to pass io into its methods to read/write it? When would you ever make a File with one io implementation and want to manipulate it with another?

No one can stop you from defining a global Io value, similar to global allocators. Definitely a bad idea for library code though.
Post reply on HN