fn foo(db: *Db) !void { ... }
fn bar() !void { ... }
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.
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!
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.
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.
Of course, if these async contexts were first class citizens then you've basically just reinvented delimited continuations, and that introduces complications that compiler writers want to avoid, which is why async/await are second citizens.
Because async/await are not values, they are ways to run/structure your code. That's why they are so infectious. If you don't want the division the only solution is to make everything of one kind. Languages like C make everything sync/blocking, while languages like Go make everything async.
That's not really the case. All you really need is a way to run async code from a sync function; "keep doing this async thing until it's done" is the primitive you need, and some languages/runtimes offer this.
On a practical note, since Rust doesn't standardise on an async runtime, it would be more accurate to say tokio solved the coloured function problem, for whatever that means. Or any and everyone else that made it easy to call one coloured function from another.
They are computations that produce values. Computations can be reified as values. What do you think functions and threads are?
As I described above, "delimited continuations" are values that subsume async/await and many other kinds of effects. You can handle async/await like any other value if they were reified as delimited continuations, but this makes the compiler writer's life much more difficult.
Supporting delimited continuations force some specific ways of performing computations. They are akin to making everything async, which proves my point: you have to make everything of one kind in order to solve the problem.
You can use ordinary direct style compilation, but all references to stack values simply have to be relative offsets, then a simple implementation of shift/reset is just capturing context and copying stack fragments, which you can do using setjmp/longjmp in C (although there are better ways [1]).
This is not akin to making everything async, nor is everything "of one kind", whatever that means. A delimited continuation is very much its own kind of thing, distinct from other values, and doesn't have to influence the function call/return semantics unless you're targeting a less flexible runtime like the JVM.
Then such references are no longer pointers, and in order to have a generic reference (that can point to both stack memory and heap memory) you have to store additional data (which one of them it points to) and conditionally use the correct one any time you access it. This is a very invasive change to the memory model.
> then a simple implementation of shift/reset is just capturing context and copying stack fragments, which you can do using setjmp/longjmp in C
That sounds like you're just reinventing green threads then, which basically forces everything to be async once you start noticing its issues.
> https://github.com/koka-lang/libhandle
This returns a 404 error for me.
> This is not akin to making everything async, nor is everything "of one kind", whatever that means.
Sure, if everything has to be able to "wait" for the result of a continuation then you're forcing async support on everything.
If instead you implement continuations as some kind of monads that users have to return from their functions then you got function coloring because you can't normally wait for the result of a continuation from a function that does not return a continuation.
Dropped the r somehow:
https://github.com/koka-lang/libhandler
> Sure, if everything has to be able to "wait" for the result of a continuation then you're forcing async support on everything.
If "forcing async support" doesn't mean that code has to change, or any other code in the call chain, then it's just meaningless pedantry.
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.
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
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.
You have the following call stack (top to bottom): a -> b -> c -> d
Function "d" does IO, so a, b and c need to pass that IO down. It's the same as with async in terms of virality.
If I understood correctly, the main benefit here is that you don't have to dance around "can I call this function or is it going to block async runtime reactor?"
I would pick async/await style over this because (I think) extra function argument is higher visual load than "async fn".
const Greeter = struct {
io: std.Io,
pub fn greet(self: Greeter, msg: []const u8) !void {
var stdout_writer = self.io.stdout.writer();
try stdout_writer.writeAll(msg);
}
}
Greeter.greet("Look ma, no coloring")On a side note: the entire "coloring" metaphor is extremely unfortunate and confusing IMO. It's somewhere at the top of my list (right beside the shroedinger's cat) of things which could've been explained better without dumbing them down.
Function coloring is indeed confusing, which is why I’ve been trying to ground this on effects instead. Effects are IMO easier to understand, and this is a straightforward example of effect typing.
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");
});
And calling blocking from non-blocking:
let result = tokio::task::spawn_blocking(|| {
5
}).await;
But consider a language that doesn't have block_on, like javascript.
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.
So we are just going to forget Go exists?
as per my understanding, golang has it implicit. Like there is no way for a developer to tell if code will run under async context or not.
That's not exactly true. Many languages return a curried version of it, which can be executed once you have a runtime.
> Semantically, passing std.Io to every function is no different from making every Node.js function async and returning a promise. Zig shifts function coloring from blocking/non-blocking choice to io/non-io.
> Complains are about how inconvenient it is to work with [blocking and non-blocking function handling] differences
"Extra argument" in this case is not much different from "extra async keyword", because you can only run I/O functions when having std.Io in scope.
I haven't written any Zig but these demonstrations give me strong vibes of how I felt when I picked up Go more than 10y ago.
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).
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.
I have not mentioned this in the post, but it's surprising how monadic I/O operations are, including async/await approach
And it is certainly in FP land to pass I/O as parameter, because everything is a function
- 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.
// 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)
}
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.
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.
Yes, but you would either create a new std.Io just for that, or use a global/semi-global std.Io from somwhere else
The function color analogy captures a pernicious viral dynamic with async where it allows only one-way composition. That just doesn’t exist with zig i/o.
audunw•6mo ago
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•6mo ago
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•6mo ago
dwattttt•6mo ago
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.
Dylan16807•6mo ago
How would you add "block on promise"? Javascript started off without the ability to block on anything, not even I/O because it didn't have I/O. Later when XMLHttpRequeest was added it was purely callback-based.
There are ways to make that API work but introducing the concept of blocking would be a big language change. It's not fixing a flaw, it's trading away some complications for a different pile of complications. There's still a conflict to resolve in language design when you want some functions that are synchronous and don't block and other functions that are asynchronous.
Edit: I guess javascript blocks on alert() but that doesn't seem like what you'd want "block on promise" to do...
dwattttt•6mo ago
If you did so in a Worker, you'd have your "don't block the UI thread" in there too.
Dylan16807•6mo ago
Blocking in the sense of blocking I/O or blocking on a system call is not possible in javascript. So again I ask what you have in mind for a "block on promise" call. The ideas that come to my mind all require significant redesigns of the execution model, or copping out by making every function async and treating it like an await.
In particular with workers in mind, I'll put it this way: If you don't allow "block on promise" in the main thread, you generally avoid these issues, but you also don't solve the problem, you still have async versus not async causing many headaches. If you do allow it on the main thread, how do you keep your page functioning? I can imagine resolutions but they all have severe compromises.
dwattttt•6mo ago
Being able to block on an async function call is just as much of a risk; if it returns quick, you live, if it returns slow, you die.
The solution to "main page unresponsive, terminate page?" is to always return promptly to the Runtime, so e.g. make everything async. But JavaScript is a language, and it doesn't just exist on web page main threads. As much as JS's proliferation everywhere else isn't my cup of tea, a blocking call in a JS cli tool is what you want.
EDIT: I guess to be explicit:
> So again I ask what you have in mind for a "block on promise" call
I expect it to have the same guarantees and risks of calling a non-async JS function.
Dylan16807•6mo ago
But in a very temporary way. If it takes seconds that's a bug, while if blocking I/O takes seconds that's normal behavior.
And I've never seen a javascript busy loop in non-malicious code.
> I expect it to have the same guarantees and risks of calling a non-async JS function.
The main guarantee is that the function will be done and have all its temporary data cleaned up before your (non-worker) execution switches to other code. And in practice you can expect it to return within .1 seconds.
That guarantee is going to be an issue if you try to introduce some kind of "block on promise". And the timing expectation is meaningful too.
woodruffw•6mo ago
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•6mo ago
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•6mo ago
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.
throwawaymaths•6mo ago
it does not, because it can take a vtable that does not call i/o
concretely:
woodruffw•6mo ago
Intuitively: if you mark a function as async, it doesn’t stop being async “colored” just because you don’t actually perform any async operations in it. This is the same thing.
throwawaymaths•6mo ago
[0] But even in that case there's not really coloring because if you provide a single io implementation there won't be different functions, even at the compiled level.
woodruffw•6mo ago
People seem to be really defensive about this, like it's a bad thing. It isn't! It's arguably a significantly cleaner way to handle what people confusingly call "coloring." But that doesn't make it not "coloring," because coloring is about effects and vitality, not about keywords and syntax.
throwawaymaths•6mo ago
2. here's what i have to say about your idea of what coloring is: That's all fine and good in theory, but in practice it makes no difference, at the user level, or at the compiler level.
woodruffw•6mo ago
> That's all fine and good in theory, but in practice it makes no difference, at the user level, or at the compiler level
Every example given so far shows Io’s virality, so I don’t know how you can assert how it doesn’t make a difference. The entire point of the design appears (reasonably) to be to introduce a token object that conveys an effect, rather than requiring a runtime to intermediate that effect.
Again, none of this is bad. Effect typing is cool. But it is, by definition, a way to color a function.
(Maybe the confusion here stems from the fact that languages like Go appear to have it “both ways” without coloring. Go is able to do that because it has an intrusive runtime that intermediates asynchronous events. Zig can’t do the same thing without making the same compromises as Go vis a vis FFI performance and ABI compatibility.)
throwawaymaths•6mo ago
woodruffw•6mo ago
throwawaymaths•6mo ago
grayhatter•6mo ago
Say you have two functions one that does some kind of IO, (say a pair of bidirectional read, write, from stdin and stdout) and another that returns a block of memory of a constant size. Would you say that one is colored, and the other isn't?
I'll also try to make an attempt at the idea I'm trying to figure out too. I genuinely can't predict which side you'll answer for, but I'm assuming you'll say that it's not colored, because while it does do IO, but only directly though the global file descriptors which have no baring on the calling conventions. Which means the decisions and impact about which color this IO function doesn't ever apply to the callers and callees. This I think is the virality you mean where the callers and callees are required to know [something] about the semantics? I probably agree you could call this coloring and defend it... It's interesting that this might be closer to the "accepted" definitions of what any language means when it says this function is colored. But I don't think this understanding most people have about the concept of coloring. Most I see are arguing about the semantic effects, much more than the "accepted" definition. I have the distinct impression that when most say coloring, the most significant implication is when and where you resolve the specific color. Will it be sync or async code, when, where, and who gets to decide.
Or perhaps I'm wrong, and you would say that one function is colored, but the other isnt? Then I'd ask if you can tell it's colored, can you tell me which color?
In both cases I'd argue it's better to embrace the semantic widening of the concept of function coloring, because what I understand from how you describe it, I feel that saying this is coloring is strictly less enlightening about the reality of the code and system together, than calling this function alpha. With zig's new IO interface, I can't tell you what the RGB values are for the color, but I can confidently say, it's alpha channel is 0xff. You might not be able to tell me what color it is, but it without a doubt isn't a pure function, interacts with IO and does have a null byte in the alpha channel.
hamandcheese•6mo ago
That is not a consequence of function coloring or syntax, it is a consequence of having multiple ways of performing IO.