Zig's New Async I/O

Zig's New Async I/O
kristoff.it

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

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

Now, technically this seems to be solved, but you still need to provide IO as a parameter. Non-IO functions don't need/take it.

It looks like a regular function call, but there's no real difference.

> 3. You can only call a red function from within another red function

This still applies. You can only call IO functions from within other IO functions.

Technically you could pass in a new executor, but is that really what you want? Not to mention that you can also do this in languages that don't claim to solve the coloring problem.

> 4. Red functions are more painful to call

I think the spirit still applies here.

> 5. Some core library functions are red

This one is really about some things being only possible to implement in the language and/or stdlib. I don't think this applies to Zig, but it doesn't apply to Rust either for instance.

Now, I think these rules need some tweaking, but the general problem behind function coloring is that of context. Your function needs some context (an async executor, auth information, an allocator, ...). In order to call such a function you also need to provide the context. Zig hasn't really solved this.

That being said, I don't think Zig's implementation here is bad. If anything, it does a great job at abstracting the usage from the implementation. This is something Rust fails at spectacularly.

However, the coloring problem hasn't really been defeated.

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

> While fibers may have looked like an attractive approach to write scalable concurrent code in the 90s, the experience of using fibers, the advances in operating systems, hardware and compiler technology (stackless coroutines), made them no longer a recommended facility.

If they go through with this, Zig will probably top out at "only as fast as Go", instead of being a true performance competitor. I at least hope the old std.fs sticks around for cases where performance matters.

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 something).

Another thing that is interesting is given a blocking posix I/O that also allows for creating processes or threads, you could build in userspace a truly asynchronous `io` object from that blocking one. It wouldn't be as efficient as one based directly on iouring, and it would be old school, but it would basically work.

Going either way (changing `io` to sync or async) the caller doesn't actually care. Yes the caller needs a context, but most modern apps rely on some form of dependency injection. Most well-factored apps would probably benefit from a more refined and domain-specific "environment" (or set of platform effects, perhaps to use the Roc terminology), not Zig's posix-flavoured standard library `io` thing.

Yes rust achieves this to some extent; you can swap an async runtime for another and your app might still compile and run fine.

Overall I like this alot - I am wondering if Richard Feldmann managed to convince Andrew Kelley that "platforms" are cool and some ideas were borrowed from Roc?