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

61–70 of 293 posts

Re: Zig's New Async I/O

#61

Post by throwawaymaths »

do_not_redeem wrote: post #28
kristoff_it wrote: post #23

Earlier quoted context omitted.

> (And before anyone mentions it, devirtualization is a myth, sorry) In Zig it's going to be a language feature, thanks to its single unit compilation model. https://github.com/ziglang/zig/issues/23367

Wouldn't this only work if there's only one implementation throughout the entire compliation unit? If you use 2 allocators in your app, your restricted function type has 2 possible callees for each entry, and you're back to the same problem.

> Wouldn't this only work if there's only one implementation throughout the entire compliation unit

in practice how often are people using more than one io in a program?

Re: Zig's New Async I/O

#62

Post by jaredklewis »

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…

So this is a tangent from the main article, but this comment made me curious and I read the original "What color is Your Function" post.

It was an interesting read, but I guess I came away confused about why "coloring" functions is a problem. Isn't "coloring" just another form of static typing? By giving the compiler (or interpreter) more meta data about your code, it can help you avoid mistakes. But instead of the usual "first argument is an integer" type meta data, "coloring" provides useful information like: "this function behaves in this special way" or "this function can be called in these kinds of contexts." Seems reasonable?

Like the author seems very perturbed that there can be different "colors" of functions, but a function that merely calculates (without any IO or side-effects) is different than one that does perform IO. A function with only synchronous code behaves very differently than one that runs code inside another thread or in a different tick of the event loop. Why is it bad to have functions annotated with this meta data? The functions behave in a fundamentally different way whether you give them special annotations/syntax or not. Shouldn't different things look different?

He mentions 2015 era Java as being ok, but as someone that’s written a lot of multithreaded Java code, it’s easy to mess up and people spam the “synchronized” keyword/“color” everywhere as a result. I don’t feel the lack of colors in Java makes it particularly intuitive or conceptually simpler.

Re: Zig's New Async I/O

#63

Post by ginko »

throwawaymaths wrote: post #57
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…

> 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…

>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?

How will that work with code mixing different Io implementations? Say a library pulled in uses a global Io instance while the calling code is using another.

I guess this can just be shot down with "don't do that" but it feels like a new kind of pitfall get get into.

Re: Zig's New Async I/O

#64

Post by throwawaymaths »

rowanG077 wrote: post #56
n42 wrote: post #30

Earlier quoted context omitted.

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…

> Unless you can show me concrete example

add io to a struct and let the struct keep track of its own io.

Re: Zig's New Async I/O

#65

Post by throwawaymaths »

ginko wrote: post #63
throwawaymaths wrote: post #57

Earlier quoted context omitted.

> 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…

>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? How will that work with code mixing different Io implementations? Say a library pulled in uses a global Io instance while the calling code is using another. I guess this can just be shot down with "don't do that" but it feels like a new kind of pitfall get get into.

> Say a library pulled in uses a global Io instance while the calling code is using another.

it'll probably carry a stigma like using unsafe does.

Re: Zig's New Async I/O

#66

Post by TUSF »

ginko wrote: post #63
throwawaymaths wrote: post #57

Earlier quoted context omitted.

> 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…

>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? How will that work with code mixing different Io implementations? Say a library pulled in uses a global Io instance while the calling code is using another. I guess this can just be shot down with "don't do that" but it feels like a new kind of pitfall get get into.

Zig already has an Allocator interface that gets passed around, and the convention is that libraries don't select an Allocator. Only provide APIs that accept allocators. If there's a certain process that works best with an Arena, then the API may wrap a provided function in an Arena, but not decide on their own underlying allocator for the user.

For Zig users, adopting this same mindset for Io is not really anything new. It's just another parameter that occasionally needs to be passed into an API.

Re: Zig's New Async I/O

#67

Post by throwawaymaths »

dminik wrote: post #24
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 ... If this was true in general, the function coloring problem wouldn't be talked about. However, the second point is more interesting. I think there's a bit of a Stockholm syndrome thing here with Zig programmers and Allocator. It's likely that Zig programmers won't mind passing around an extra param. If anything, it would make sense to me to have…

> But I guess it's going to be 2 params from now on.

>> So, if you discover that a code path you previously thought was pure actually does need to perform IO, then you don't need to apply some nasty viral change; you just grab `my_thing.io

Re: Zig's New Async I/O

#68

Post by ksec »

mlugg wrote: post #11
do_not_redeem wrote: post #5

I'm generally a fan of Zig, but it's a little sad seeing them go all in on green threads (aka fibers, aka stackful coroutines). Rust got rid of their Runtime trait (the rough equivalent of Zig's Io) before 1.0 because it performed badly. Languages and OS's have had to learn this lesson the hard way over and over again: https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13... > While fibers may have looked like…

I'm not sure how you got the perception that we're going "all in" on green threads, given that the article in OP explicitly mentions that we're hoping to have an implementation based on stackless coroutines, based on this Zig language proposal: https://github.com/ziglang/zig/issues/23446 Performance matters; we're not planning to forget that. If fibers turn out to have unacceptable performance characteristics, then t…

That is lovely to hear. I think the general conscious is that not a single programming language has done Async right. So people are a little sceptical. But Andrew and the team so far seems to have the do it right mentality. So I guess people should be a little more optimistic.

Cant wait for 0.15 coming out soon.

Re: Zig's New Async I/O

#69

Post by deepsun »

pjmlp wrote: post #48
schrodinger wrote: post #44

Earlier quoted context omitted.

Why do you encourage avoiding it? Afaik it's the only way to early-abort an operation since Goroutines operate in a cooperative, not preemptive, paradigm. To be very clear, I'm asking this completely in good faith looking to learn something new!

You are expecting them to actually check the value, there is nothing preemptive. Another approach is special messages over a side channel.

So instead of a context you need to pass a a channel. Same problem.

Re: Zig's New Async I/O

#70

Post by [deleted] »

jaredklewis wrote: post #62
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…

So this is a tangent from the main article, but this comment made me curious and I read the original "What color is Your Function" post. It was an interesting read, but I guess I came away confused about why "coloring" functions is a problem. Isn't "coloring" just another form of static typing? By giving the compiler (or interpreter) more meta data about your code, it can help you avoid mistakes. But instead of the u…

[deleted]
Post reply on HN