[HN Gopher] Zig's new I/O: function coloring is inevitable?
___________________________________________________________________
Zig's new I/O: function coloring is inevitable?
Author : ivanjermakov
Score : 14 points
Date : 2025-07-13 15:57 UTC (7 hours ago)
(HTM) web link (blog.ivnj.org)
(TXT) w3m dump (blog.ivnj.org)
| audunw wrote:
| 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.
| camgunz wrote:
| 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.
| kristoff_it wrote:
| If you want to go down that route, any function that has, or
| doesn't have, any given resource is colored then.
| fn foo(db: *Db) !void { ... } fn bar() !void { ... }
|
| 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.
| n42 wrote:
| 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!
| orphea wrote:
| Related discussion (Zig's New Async I/O):
| https://news.ycombinator.com/item?id=44545949
___________________________________________________________________
(page generated 2025-07-13 23:01 UTC)