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

21–30 of 293 posts

Re: Zig's New Async I/O

#21

Post by do_not_redeem »

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…

Does the BDFL want this though, or is it just one person's opinion that it might be nice? Given how he has been aggressively pruning proposals, I don't put any hope in them anymore unless I see some kind of positive signal from him directly.

e.g. I'd feel a lot more confident if he had made the coroutine language feature a hard dependency of the writergate refactor.

Re: Zig's New Async I/O

#22

Post by kristoff_it »

do_not_redeem wrote: post #21
mlugg wrote: post #11

Earlier quoted context omitted.

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…

Does the BDFL want this though, or is it just one person's opinion that it might be nice? Given how he has been aggressively pruning proposals, I don't put any hope in them anymore unless I see some kind of positive signal from him directly. e.g. I'd feel a lot more confident if he had made the coroutine language feature a hard dependency of the writergate refactor.

mlugg is in the Zig core team

Re: Zig's New Async I/O

#23

Post by kristoff_it »

do_not_redeem wrote: post #18
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?

I think it's just the Zig philosophy to care more about binary size than speed. Allocators have the same tradeoff, ArrayListUnmanaged is not generic over the allocator, so every allocation uses dynamic dispatch. In practice the overhead of allocating or writing a file will dwarf the overhead of an indirect call. Can't argue with those binary sizes. (And before anyone mentions it, devirtualization is a myth, sorry)

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

Re: Zig's New Async I/O

#24

Post by dminik »

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…

> 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 IO contain an allocator too. Allocation is a kind of IO too. But I guess it's going to be 2 params from now on.

Re: Zig's New Async I/O

#25

Post by ismailmaj »

kristoff_it wrote: post #16
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…

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

Re: Zig's New Async I/O

#27

Post by do_not_redeem »

kristoff_it wrote: post #22
do_not_redeem wrote: post #21

Earlier quoted context omitted.

Does the BDFL want this though, or is it just one person's opinion that it might be nice? Given how he has been aggressively pruning proposals, I don't put any hope in them anymore unless I see some kind of positive signal from him directly. e.g. I'd feel a lot more confident if he had made the coroutine language feature a hard dependency of the writergate refactor.

mlugg is in the Zig core team

I'm aware, but Zig isn't a democracy where the core team votes, right? Has Andrew actually expressed that he wants the proposal? Without that we're left with scraps like this commit message where he seems ambivalent. https://github.com/ziglang/zig/commit/d6c90ceb04f8eda7c6b711...

Andrew, I know you read these threads sometimes, give us a sign so I can go down the mountain with my stone tablets and tell the people whether we'll have coroutines

Re: Zig's New Async I/O

#28

Post by do_not_redeem »

kristoff_it wrote: post #23
do_not_redeem wrote: post #18

Earlier quoted context omitted.

I think it's just the Zig philosophy to care more about binary size than speed. Allocators have the same tradeoff, ArrayListUnmanaged is not generic over the allocator, so every allocation uses dynamic dispatch. In practice the overhead of allocating or writing a file will dwarf the overhead of an indirect call. Can't argue with those binary sizes. (And before anyone mentions it, devirtualization is a myth, sorry)

> (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.

Re: Zig's New Async I/O

#29

Post by dminik »

kristoff_it wrote: post #16
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…

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…

Well, it's not really a joke. That's a valid strategy that languages use. In Go, every function is "async". And it basically blocks you from doing FFI (or at least it used to?). I wonder if Zig will run into similar issues here.

> 1. Code can't be reused because the async keyword statically colors a function

This is fair. And it's also a real pain point with Rust. However, it's funny that the "What color is your function?" article doesn't even really mention this.

> 2. Using async and await opts you automatically into stackless coroutines with no way of preventing that

This however I don't think is true. Async/await is mostly syntax sugar.

In Rust and C# it uses stackless coroutines.

In JS it uses callbacks.

There's nothing preventing you from making await suspend a green thread.

Re: Zig's New Async I/O

#30

Post by n42 »

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…

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.
Post reply on HN