Zig's new plan for asynchronous programs

Post by SkiFire13 » Thu, Dec 04, 2025, 7:49 AM UTC

zamalek wrote: post #102

SkiFire13 wrote: post #85

Earlier quoted context omitted.

The function coloring problem actually comes up when you implement the async part using stackless coroutines (e.g. in Rust) or callbacks (e.g. in Javascript). Zig's new I/O does neither of those for now, so hence why it doesn't suffer from it, but at the same time it didn't "solve" the problem, it just sidestepped it by providing an implementation that has similar features but not exactly the same tradeoffs.

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…

Post by geon » Thu, Dec 04, 2025, 9:33 AM UTC

throwawaymaths wrote: post #134

SkiFire13 wrote: post #84

Earlier quoted context omitted.

> 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 single compilation unit). AFAIK this still leaked through function pointers, which were still sync or async (and this was not visible in their type)

Pretty sure the Zig team is aware of this and has plans to fix it before they re-release async.

Post by lukaslalinsky » Thu, Dec 04, 2025, 2:30 PM UTC

ghosty141 wrote: post #208

unscaled wrote: post #205

Earlier quoted context omitted.

Let's revisit the original article[1]. It was not about arguments, but about the pain of writing callbacks and even async/await compared to writing the same code in Go. It had 5 well-defined claims about languages with colored functions: 1. Every function has a color. This is true for the new zig approach: functions that deal with IO are red, functions that do not need to deal with IO are blue. 2. The way you call a…

In my opinion you must have function coloring, it's impossible to do async (in the common sense) without it. If you break it down one function has a dependency on the async execution engine, the other one doesn't, and that alone colors them. Most languages just change the way that dependency is expressed and that can have impacts on the ergonomics.

    defer stream.close(io);

    var read_buffer: [1024]u8 = undefined;
    var reader = stream.reader(io, &read_buffer);

    var write_buffer: [1024]u8 = undefined;
    var writer = stream.writer(io, &write_buffer);

    while (true) {
        const line = reader.interface.takeDelimiterInclusive('\n') catch |err| switch (err) {
            error.EndOfStream => break,
            else => return err,
        };
        try writer.interface.writeAll(line);
        try writer.interface.flush();
    }

Post by geon » Thu, Dec 04, 2025, 5:41 PM UTC

tome wrote: post #225

AndyKelley wrote: post #86

Earlier quoted context omitted.

It's not a monad because it doesn't return a description of how to carry out I/O that is performed by a separate system; it does the I/O inside the function before returning. That's a regular old interface, not a monad.

> 1. a description of how to carry out I/O that is performed by a separate system > 2. does the I/O inside the function before returning How do you distinguish those two things? To put my cards on the table, I believe Haskell does 2, and I think my Haskell effect system Bluefin makes this abundantly clear. (Zig's `Io` seems to correspond to Bluefin's `IOE`.) There is a persistent myth in the Haskell world (and beyond…

Post by thinkharderdev » Thu, Dec 04, 2025, 9:56 PM UTC

hansvm wrote: post #258

thinkharderdev wrote: post #220

Earlier quoted context omitted.

> If it were written with async it would likely have enough other baggage that it wouldn't fit or otherwise wouldn't work I'm unclear what this means. What is the other baggage in this context?

In context (embedded programming, which in retrospect is still too big of a field for this comment to make sense by itself; what I meant was embedded programming on devices with very limited RAM or other such significant restrictions), "baggage" is the fact that you don't have many options when converting async high-level code into low-level machine code. The two normal things people write into their languages/compil…