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

Zig's New Async I/O

kristoff.it

Post reply on HN
Print view View original

51–60 of 293 posts

Re: Zig's New Async I/O

#51

Post by throwawaymaths »

dminik wrote: post #3

I feel that I have to point this out once again, because the article goes so far as to state that: > With this last improvement Zig has completely defeated function coloring. I disagree with this. Let's look at the 5 rules referenced in the famous "What color is your function?" article referenced here. > 1. Every function has a color Well, you don't have async/sync/red/blue anymore, but you now have IO and non-IO fun…

> Technically you could pass in a new executor, but is that really what you want?

why does it have to be new? just use one executor, set it as const in some file, and use that one at every entrypoint that needs io! now your io doesn't propagate downwards.

Re: Zig's New Async I/O

#52

Post by philwelch »

dminik wrote: post #20
andyferris wrote: post #7

Earlier quoted context omitted.

I think of it this way. Given an `io` you can, technically, build another one from it with the same interface. For example given an async IO runime, you could create an `io` object that is blocking (awaits every command eagerly). That's not too special - you can call sync functions from async functions. (But in JavaScript you'd have trouble calling a sync function that relies on `await`s inside, so that's still somet…

> but most modern apps rely on some form of dependency injection Does Zig actually do anything here? If anything, this seems to be anti-Zig, where everything must be explicit.

Passing in your dependencies as function arguments is a form of dependency injection. It is the simplest and thus arguably best form of dependency injection.

Re: Zig's New Async I/O

#53

Post by throwawaymaths »

ginko wrote: post #47
mlugg wrote: post #8

Earlier quoted context omitted.

The key difference to typical async function coloring is that `Io` isn't something you need specifically for asynchronicity; it's something which (unless you make a point to reach into very low-level primitives) you will need in order to perform any IO, including reading a file, sleeping, getting the time, etc. It's also just a value which you can keep wherever you want, rather than a special attribute/property of a…

> It's quite rare for a function to unexpectedly gain a dependency on "doing IO" in general. From the code sample it looks like printing to stdio will now require an Io param. So won’t you now have to pass that down to wherever you want to do a quick debug printf?

std.debug.print(..) prints to stderr whuch does not need an io param.

Re: Zig's New Async I/O

#54

Post by throwawaymaths »

ismailmaj wrote: post #25
kristoff_it wrote: post #16

Earlier quoted context omitted.

Here's a trick to make every function red (or blue? I'm colorblind, you decide): var io: std.Io = undefined; pub fn main() !void { var impl = ...; io = impl.io(); } Just put io in a global variable and you won't have to worry about coloring in your application. Are your functions blue, red or green now? Jokes aside, I agree that there's obviously a non-zero amount of friction to using the `Io` intreface, but it's som…

The global io trick would totally be valid if you’re writing an application (i.e. not a library) and don’t have use of two different implementations of io

you could still have a library-global io, let the user set it as desired.

> use of two different implementations of io

functionally rare situation.

Re: Zig's New Async I/O

#55

Post by throwawaymaths »

cryptonector wrote: post #42
dminik wrote: post #3

I feel that I have to point this out once again, because the article goes so far as to state that: > With this last improvement Zig has completely defeated function coloring. I disagree with this. Let's look at the 5 rules referenced in the famous "What color is your function?" article referenced here. > 1. Every function has a color Well, you don't have async/sync/red/blue anymore, but you now have IO and non-IO fun…

> Well, you don't have async/sync/red/blue anymore, but you now have IO and non-IO functions. > However, the coloring problem hasn't really been defeated. Well, yes, but if the only way to do I/O were to have an Io instance to do it with then Io would infect all but pure(ish, non-Io) functions, so calling Io functions would be possible in all but those contexts where calling Io functions is explicitly something you d…

Zig's not really about hiding things but you could put it in an options struct that has defaults unless overridden at compile time.

Re: Zig's New Async I/O

#56

Post by rowanG077 »

n42 wrote: post #30
dminik wrote: post #19

Earlier quoted context omitted.

To me, there's no difference between the IO param and async/await. Adding either one causes it to not be callable from certain places. As for the second thing: You can do that, but... You can also do this in Rust. Yet nobody would say Rust has solved function coloring. Also, check this part of the article: > In the less common case when a program instantiates more than one Io implementation, virtual calls done throug…

You’re allowed to not like it, but that doesn’t change that your argument that this is a form of coloring is objectively false. I’m not sure what Rust has to do with it.

Sure it is a function coloring. Just in a different form. `async` in other languages is something like an implicit parameter. In zig they made this implicit parameter explicit. Is that more better/more ergonomic? I don't know yet. The sugar is different, but the end result the same. Unless you can show me concrete example of things that the approach zig has taken can do that is not possible in say, rust. Than I don't buy that it's not just another form of function coloring.

Re: Zig's New Async I/O

#57

Post by throwawaymaths »

dminik wrote: post #19
n42 wrote: post #12

Earlier quoted context omitted.

Aside from the ridiculous argument that function parameters color them, the assertion that you can’t call a function that takes IO from inside a function that does not is false, since you can initialize one to pass it in

To me, there's no difference between the IO param and async/await. Adding either one causes it to not be callable from certain places. As for the second thing: You can do that, but... You can also do this in Rust. Yet nobody would say Rust has solved function coloring. Also, check this part of the article: > In the less common case when a program instantiates more than one Io implementation, virtual calls done throug…

> Adding either one causes it to not be callable from certain places.

you can call a function that requires an io parameter from a function that doesn't have one by passing in a global io instance?

as a trivial example the fn main entrypoint in zig will never take an io parameter... how do you suppose you'd bootstrap the io parameter that you'd eventually need. this is unlike other languages where main might or might not be async.

Re: Zig's New Async I/O

#58

Post by [deleted] »

mlugg wrote: post #8
dminik wrote: post #3

I feel that I have to point this out once again, because the article goes so far as to state that: > With this last improvement Zig has completely defeated function coloring. I disagree with this. Let's look at the 5 rules referenced in the famous "What color is your function?" article referenced here. > 1. Every function has a color Well, you don't have async/sync/red/blue anymore, but you now have IO and non-IO fun…

The key difference to typical async function coloring is that `Io` isn't something you need specifically for asynchronicity; it's something which (unless you make a point to reach into very low-level primitives) you will need in order to perform any IO, including reading a file, sleeping, getting the time, etc. It's also just a value which you can keep wherever you want, rather than a special attribute/property of a…

[deleted]

Re: Zig's New Async I/O

#59

Post by geodel »

do_not_redeem wrote: post #9
dundarious wrote: post #6

Earlier quoted context omitted.

It's hardly "all-in" if it is merely one choice of many, and the choice is made in the executable not in the library code.

I have definitely gotten the impression that green threads will be the favored implementation, from listening to core team members and hanging around the discord. Stackless coroutines don't even exist in the language currently.

> Stackless coroutines don't even exist in the language currently.

And green thread exists in language?

Re: Zig's New Async I/O

#60

Post by throwawaymaths »

henrikl wrote: post #15

Seeing a systems language like Zig require runtime polymorphism for something as common as standard IO operations seems off to me -- why force that runtime overhead on everyone when the concrete IO implementation could be known statically in almost all practical cases?

> why force that runtime overhead on everyone

pretty sure the intent is for systems that only use one io to have a compiler optimization that elides the cost of double indirection... but also, you're doing IO! so usually something else is the bottleneck, one extra indirection is likely to be peanuts.

Post reply on HN