Zig's new I/O: function coloring is inevitable?
44 comments
·July 13, 2025kristoff_it
woodruffw
> Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me.
In the sense of effect/capability typing, I think the answer is yes.
"Coloring" isn't magical, it's just a way to describe effects. Those effect can be described by keywords (`async` in JS, `throws` in Java, etc.) or special token parameters/types (what Zig does), but the consequences are the same: the effect propagates to the caller, and the caller becomes responsible for dealing with it.
nextaccountic
Yeah, parameter passing can be seen as some kind of effect (like the Reader monad in Haskell). Passing parameters down the call stack is viral just like function coloring (if you need to do i/o and thus need to receive an io parameter, then your caller must receive an io parameter too, recursively; this is analogous to adding a keyword async in front of your function, and to its callers recursively). The solution is probably some sort of implicit parameter, again, like the Reader monad.
Note: async fn in Rust is also just a fn (in Rust's case, a fn that returns a future). It turns out that returning a future, or receiving as parameter a reference to the runtime, are equivalent in some sense
koiueo
> Passing parameters down the call stack is viral
It's in a different league comparing to async-await abomination. For one, you can store parameter on a struct thus working around the "virality" on a call site.
n42
I've been trying to beat this point in and failing. If a parameter type creates "colors", you can extrapolate that to an infinite set of colors in every single language and every single standard library, and the discussion on colors becomes meaningless.
Some people are so focused on categorical thinking that they are missing the forest for the trees.
The colors are a means of describing an observed outcome -- in Node's case, callback hell, in Rust's, 4 different standard libraries. Whatever it may be, the point is not that there are colors, it's the impact on there being colors.
> But there is a catch: with this new I/O approach it is impossible to write to a file without std.Io!
This sentence just makes me laugh, like it's some kind of "gotcha". It is the ENTIRE BASIS of the design!
dwattttt
> you can extrapolate that to an infinite set of colors in every single language and every single standard library, and the discussion on colors becomes meaningless.
It's more that discussion about most of them becomes meaningless, because they're trivial. We only care when it's hard to swap between "colours", so e.g. making it easy to call an Io function from a non-Io function "removes" the colouring problem.
hamandcheese
> so e.g. making it easy to call an Io function from a non-Io function "removes" the colouring problem.
Exactly. In golang (which is also a cooperatively multithreaded runtime if I understand correctly), calling a function that needs IO does not infect the callers type signature.
In async rust, and in "async param" zig, it does.
null
alex_hirner
> The virality of async await is that once you mark a function async, then you can only call it from another async function
That's not exactly true. Many languages return a curried version of it, which can be executed once you have a runtime.
rk06
Well said. Honestly I don't understand this "function coloring argument" at all in zig's context.
Function is the smallest unit of logic. And function parameter is the fundamental way to control it.so, in theory, __A function parameter is the smallest possible design choice you have to control async vs sync__
There is no way to reduce it further. As you need to encode this somehow, otherwise it will be implicit and very hard to debug.
functions can compose. Function parameters can be composed. Making this a solid design choice.
Zig has somehow achieved this feat of decomposing async/sync to a single parameter. This deserves an ovation Other langs should take note.
metaltyphoon
> in theory, __A function parameter is the smallest possible design choice you have to control async vs sync__
So we are just going to forget Go exists?
tcfhgj
> The virality of async await is that once you mark a function async, then you can only call it from another async function
Rust calling async function in non-async function:
...
// Create the runtime
let rt = Runtime::new().unwrap();
// Get a handle from this runtime
let handle = rt.handle();
// Execute the future, blocking the current thread until completion
handle.block_on(async {
println!("hello");
});
vlovich123
Of course, spinning up a new runtime within the context of a boundary like that is probably wasteful (lots of new threads created if you’re not careful). But you could stash that runtime behind a OnceLock (you’d need to block_on the Handle I imagine rather than the Runtime directly, but doable).
And calling blocking from non-blocking:
let result = tokio::task::spawn_blocking(|| {
5
}).await;
audunw
I really don’t agree with the idea that this is functional colouring. Then we have to start talking about function colouring in a whole bunch of new contexts like with Zigs explicit passing of allocator. Or any other parameter that needs to be explicitly passed to use some kind of interface.
I think we should stick to talking about colouring when there is special calling conventions or syntax, which has the consequence of having to write separate libraries/modules for async code and non-async code.
That is the significant problem we have been seeing with many async implementation, and the one which Zig apparently fully solves.
dwattttt
> Then we have to start talking about function colouring in a whole bunch of new contexts like with Zigs explicit passing of allocator.
That's pretty much where we are though. If you have a function that isn't passed an allocator, and now it needs to call a function that does take an allocator, we're in the same place.
Rust's 'async' keyword changes the type of the return value, but you can just write the different return value yourself; it's 'coloured' purely by what it means to be returning a 'Future'.
koolala
So its impossible to get an allocator through a different means from inside a function? It must be passed in?
dwattttt
No, it's entirely possible. And that's why we don't think about "has an allocator" as a colouring problem.
Likewise if JavaScript had an easy way to get a handle to its Runtime, and a function "block on promise" in its early days, we'd have never had all these "colouring" arguments.
woodruffw
This is effectively a special calling convention: Zig expects you to pass in a "token" object that communicates a kind of effect (I/O in this case). No token, no effect (modulo a soundness hole).
This is not a new pattern, and I think it's a pretty good one (and is arguably more ergonomic and general than syntax-level effects). But it's quintessential function coloring.
throwawaymaths
> Zig expects you to pass
It does no such thing. you could pass a function a vtable and the vtable could have one implementation that calls an io stashed in the parent of the vtable, and a different vtable that doesnt and the function calling the vtable would be none the wiser. what is the color of the function that took the vtable?
this is not just academic; it would be for example the basis for mocked integration tests on a database or over the net api call.
woodruffw
That's a calling convention, with indirection. You need some kind of capability token for this kind of asynchronicity scheme; it doesn't matter how you get it, but it needs to be there.
To be clear, there's nothing wrong with this; it's just another way to encode capabilities/effects.
> what is the color of the function that took the vtable?
It has the I/O effect.
hamandcheese
> which has the consequence of having to write separate libraries/modules for async code and non-async code.
That is not a consequence of function coloring or syntax, it is a consequence of having multiple ways of performing IO.
SkiFire13
I believe Zig's new I/O is neither colored nor not colored, instead the design is orthogonal to that. You won't be able to make code magically async by just swapping the implementation of Io, instead you'll need some kind of runtime that allows functions to wait without blocking OS threads. Depending on how this is implemented (if it's possible at all) you'll have colored functions or not.
et1337
I think this is a good kind of function coloring. It would avoid some scars I have from:
- seemingly harmless functions that unexpectedly end up writing four different files to disk.
- Packages that do I/O or start threads when you simply import them.
jmull
With Zig I/O you can call i/o functions from non-i/o functions and non-i/o functions from i/o functions.
In the analogy of “What color is your function”, you can call blue functions from red functions and red functions from blue functions.
The pernicious viral nature of function coloring doesn’t apply.
Surac
i never got warm with this async/await style of calling things. i much more prefer using threads/fibers/protothreads instead. Sure you have to be more expicit on creating and controlling these and also passing around data may get more complex, but at least they do not gloss over the underlying problems async and await tries to cover up
camgunz
Look, either you move the program counter to a different place in memory (function call) or you push a task into an event loop. Even if you somehow elide all these differences, they're so different under the hood you'll always have to know in some circumstances. It's honestly wild we conflate them at all.
andyferris
I am actually really excited about this.
The issues I've had with function colouring had to do with trying to compose code using (or expecting) blocking effects with those using async effects in NodeJS - if one library has a higher-order function that expects a non-async function and you have functionality which is provided to you as async, it can be very difficult to plumb them together! And if it's the other way around, it can be quite the performance killer (think how much faster better-sqlite3 is than alternatives). Zig's approach eliminates this problem, AFAICT.
If I had to choose between having to pass through an effect handler like `io` or write `async` everywere, the former seems like a better use of my time. It's explicit, but that can be good.
It also fits Zig well with the allocator. Code can expect an allocator or perhaps an allocator and `io`, or perhaps neither. It's analogous to Rust code that is core vs alloc/nostd vs std.
I am slightly amused that a "C-but-better" language is going to have an `io` passed through non-pure functions much like Haskell. It's that idea combined with Rust's pluggable async runtimes (and stackless concurrency) combined with Roc's "platforms" - but for systems programmers. Quite amazing.
hiccuphippo
I don't care about the color of the function. What matters is if you'll have to write two versions of the function, and this seems to solve that.
dwattttt
Function colouring created a lot of angst when it first came about, particularly because of the difficulties of calling a function of one colour from another. Whether that was possible, what it actually meant, wasn't really well defined.
As other comments have said, there's nothing special about "colouring"; sync/async functions are a case where those above problems are tough, but simpler versions of the problem are everywhere and we don't freak out about them e.g. call a fallible function from an infallible function.
It really all turns on how easy it is to ultimately make the call to the other "function" colour. In Zig's case, if its easy to get an Io in a function that didn't take an Io, it's a non-issue. Likewise for the "fallible function call from infallible function": if it fails, do something that doesn't result in the infallible function failing (do something else? Terminate? Anything will do).
koiueo
If we apply your logic, then every mainstream language has the coloring problem with not just two, but a multitude of colors.
// OMG we can't call this without passing the service
// This function is people-colored
public Person findPersonByName(PeopleService service, String name) {
// OMG we can't find without the service
service.find(name)
}
vips7L
This is off topic. But I really hate “services”. They always are just some random collection of functions and aren’t a real object at all.
koiueo
I think I know what you are talking about. In a typical three-tier enterprise application there's no clear separation of concerns between "services" and DAO/Repo... And this is due to how most persistence libraries are designed: they eagerly execute side-effects, this breaks composability due to poor transaction control, so you end up leaking a lot of your business logic into your supposedly persistence layer.
Take a look at Scala's doobie[1]. Any doobie operation returns a `ConnectionIO`, which is only a description of an operation (free monad). With a proper doobie usage the DAO layer is an algebra of possible persistence-related operations, and the service layer implements business logic by combining primitive ConnectionIOs and interpreting them with full control of transaction boundaries.
vips7L
I’m sorry but I just don’t enjoy functional Scala.
orphea
Related discussion (Zig's New Async I/O): https://news.ycombinator.com/item?id=44545949
If you want to go down that route, any function that has, or doesn't have, any given resource is colored then.
Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me.The virality of async await is that once you mark a function async, then you can only call it from another async function, which forces you to mark more functions async, which in turn means that if you want to use blocking I/O APIs then you just can't because it's incompatible with your execution model because by daring to express asynchronicity of operations, you were forcefully opted into stackless coroutines.
That's what Zig solves, and that's what is real function coloring. People have written reimplementations of the same libraries multiple times because of it.
https://github.com/redis/redis-py https://github.com/jonathanslenders/asyncio-redis
Just as an example. Note also how, coincidentally, this duplication of effort resulted in asyncio-redis being semi-abandoned and looking for maintainers. And you have to have both libraries because the asyncio one can't do blocking, and vice versa the other one can't do async.
Would you write two instances of essentially the same library just because one is missing an argument that gives it access to an `Io` interface? No, because you would just pass that extra argument around and nothing else would have to change.