Comment by dminik

> You can't pass around "async/await" as a value attached to another object

Sure you can? You can just pass e.g. a Task around in C# without awaiting it, it's when you need a result from a task that you must await it.

Sure you can. An `async` function in Javascript is essentially a completely normal function that returns a promise. The `async`/`await` syntax is a convenient syntax sugar for working with promises, but the issue would still exist if it didn't exist.

More to the point, the issue would still exist even if promises didn't exist — a lot of Node APIs originally used callbacks and a continuation-passing style approach to concurrency, and that had exactly the same issues.

Other commenters have already provided examples for other languages, and it's the same for Rust: async functions are just regular functions that return an impl Future type. As a sync function, you can call a bunch of async functions and return the futures to your caller to handle, or you can block your current thread with the block_on function typically available through a handle (similar to the Io object here) provided by your favorite async runtime [0].

In other words, you don't need such an Io object upfront: You need it when you want to actually drive its execution and get the result. From this perspective, the Zig approach is actually less flexible than Rust.

[0]: https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.htm...

Conceptually, there's not much of a difference.

If you have a sync/non-IO function that now needs to do IO, it becomes async/IO. And since IO and async are viral, it's callers must also now be IO/async and call it with IO/await. All the way up the call stack.

You can call an async function from a function that is not async by passing in a global runtime (/ event loop).

As a trivial example the main entry point in rust is never async. How’d you suppose you’d bootstrap the runtime that you’d eventually need.

This is pretty much like every other langage.

>you can call a function that requires an io parameter from a function that doesn't have one by passing in a global io instance?

How will that work with code mixing different Io implementations? Say a library pulled in uses a global Io instance while the calling code is using another.

I guess this can just be shot down with "don't do that" but it feels like a new kind of pitfall get get into.

It's funny, but I do actually like it. It's just that it walks like a duck, swims like a duck and quacks like a duck.

I don't have a problem with IO conceptually (but I do have a problem with Zig ergonomics, allocator included). I do have a problem with claiming you defeated function coloring.

Like, look. You didn't even get rid of await ...

> try a_future.await(io);

Sure it is a function coloring. Just in a different form. `async` in other languages is something like an implicit parameter. In zig they made this implicit parameter explicit. Is that more better/more ergonomic? I don't know yet. The sugar is different, but the end result the same. Unless you can show me concrete example of things that the approach zig has taken can do that is not possible in say, rust. Than I don't buy that it's not just another form of function coloring.