So I did a bit of research into how this works in Zig under the hood, in terms of compilation.
First things first, Zig does compile async fns to a state machine: https://github.com/ziglang/zig/issues/23446
The compiler decides at compile time which color to compile the function as (potentially both). That's a neat idea, but... https://github.com/ziglang/zig/issues/23367
> It would be checked illegal behavior to make an indirect call through a pointer to a restricted function type when the value of that pointer is not in the set of possible callees that were analyzed during compilation.
That's... a pretty nasty trade-off. Object safety in Rust is really annoying for async, and this smells a lot like it. The main difference is that it's vaguely late-bound in a magical way; you might get an unexpected runtime error and - even worse - potentially not have the tools to force the compiler to add a fn to the set of callees.
I still think sans-io at the language level might be the future, but this isn't a complete solution. Maybe we should be simply compiling all fns to state machines (with the Rust polling implementation detail, a sans-io interface could be used to make such functions trivially sync - just do the syscall and return a completed future).
Maybe I'm missing something, but that's still a proposal, which also assumes an implementation for the other proposal you linked and that also doesn't exist yet.
For now I would refrain from commenting on non-existing functionality.
> I still think sans-io at the language level might be the future, but this isn't a complete solution.
I'm not sure what about this is really at the language level (only stackless coroutines appear to require language level support, and it's still unclear if it's really possible to implement them). However I do agree that a sans-io, or at least dependency injection for I/O is a great improvement on the library side, and it's something I'd like to see in Rust too.
Can you be more specific what is missing in sans-io with explicit state machine for static and dynamic analysis would not be a complete solution? Serializing the state machine sounds excellent for static and dynamic analysis. I'd guess the debugging infrastructure for optimization passes and run-time debugging are missing or is there more?
I don't see how that's not the exact same situation.
By the way, Rust's runtime also have a similar issue to Zig's `Io` (making the runtime available to the code, similarly to how you need to make an `Io` instance available in Zig). Rust runtimes just decided to use thread locals for that, and nothing stops you from doing the same in Zig if you want to.
I hope you can see that this is all orthogonal to the "colored functions" problem. When I was talking about tradeoffs however I was referring to the use of a threaded/green thread implementation under the hood as opposed to a stackless coroutine. The first two are less invasive at the language level and don't require function coloring (hence why Zig didn't solve, but also doesn't have, function coloring!) however they can be more limiting (they are not always available, especially on embedded and on wasm) and less extensible (most operations need to be explicitly supported in `Io`, as opposed to being implementable by anyone).
A great example is React Suspense. To suspend a component, the render function throws a Promise. To trigger a parent Error Boundary, the render function throws an error. To resume a component, the render function returns a result. React never made the suspense API public because it's a footgun.
If a JS Promise were inspectable, a synchronous render function could poll its result, and suspended components would not need to use throw to try and extend the language.
Well, technically you can run a nested event loop, I guess. But that's such a heavy sync-wrapping-async solution that it's rarely used other than as a temporary hack in legacy code.
This Io business is isomorphic to async/await in Rust or Python [1]. Go also has a built-in "event loop"-type thing, but decidedly does not have a coloring problem. I can't think of any languages besides JS that do.
context is kind of a function color in go, and it's also a function argument.
Looking back at the original function coloring post [1], it says:
> It is better. I will take async-await over bare callbacks or futures any day of the week. But we’re lying to ourselves if we think all of our troubles are gone. As soon as you start trying to write higher-order functions, or reuse code, you’re right back to realizing color is still there, bleeding all over your codebase.
So if this is isomorphic to async/await, it does not "solve" the coloring problem as originally stated, but I'm starting to think it's not much of a problem at all. Some functions just have different signatures from other functions. It was only a huge problem for JavaScript because the ecosystem at large decided to change the type signatures of some giant portion of all functions at once, migrating from callbacks to async.
[1]: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Zig's new I/O does neither of those for now, so hence why it doesn't suffer from it, but at the same time it didn't "solve" the problem, it just sidestepped it by providing an implementation that has similar features but not exactly the same tradeoffs.