The color doesn't matter
In a recent blog post, Loris Cro highlighted the new direction for Zig’s approach to async I/O. Various discussions have since unfolded on whether or not this design really removes function coloring or not.
I can see why if you squint at the design in a certain way, you might see red and blue. Personally, I think calling it coloring is a stretch; but I’m not sure the answer to whether it is or isn’t matters. It’s a fun philosophical debate, but it’s missing the point.
What matters most in this conversation is the downstream impact these designs have on the language and ecosystem. JavaScript’s breed of function coloring created a sync world, a callback world, and a promise world. Rust’s function colors has created four standard libraries and counting, and still doesn’t seem to have a solution for library authors.
The Zig team has made the claim that their design (whether colored or not) has found a way to mitigate the downstream impact on library authors and language users. Doing so has come with some trade-offs, but they claim to have designed for the majority use case. Their claim is:
- The standard library won’t have to care about colors.
- Your library won’t have to care about colors.
- Your application gets to decide what your favorite color is.
If true, and they back this up with code samples in the blog post, it would solve the core problem that function colors often create: ecosystem fragmentation. That you have to pass around, or retrieve, a std.Io interface from somewhere isn’t some kind of limitation – it’s the entire point.