Read the article, the new Zig async/await interface doesn't imply the typical async/await state-machine code transformation. You can write a simple blocking runtime, or a green-thread implementation, or a thread-pool, or the state-machine approach via stackless coroutines (but AFAIK this needs a couple of language builtins which then must be implemented in an IO implementation).

Async/await tend to be IO bound, in zigs case hiw can i know what to use and when? Say i do a db call, thats clearly IO, and later do heavy CPU thing, now how do i know that the CPU thing does not block inside my async io thing?

I guess its pure luck if the io implementation can handle both, but who knows?

> how do i know that the CPU thing does not block inside my async io thing?

I think it's common sense to not interweave IO with long-running CPU, hence sans IO.

If you want to go that route, we already have solutions: goroutines and beam processes.

This was my point. With Go it does not matter, i can do IO or CPU both with Gos concurrency (CSP), but with async/await i usully cannot, i assume this is not something Zig is planning on, as it seems to be all about IO.

Because it allows multiple topologies of producers and consumers.

No idea what that means.. Do you have a concrete example of what CPS allows and async/await doesn't?

I believe async/await means you have a single consumer (caller) and a single producer (callee) and only a single value will be produced (resolved).

With CPS you may send and receive many times over to whomever and from whomever you like.

In JavaScript you may write..

    const fetchData = async () => {
        // snip
        return data;
    }

    const data = await fetchData();

And in Go you might express the same like..

    channel := make(chan int);
    
    go func() {
        // snip
        channel <- data;
    }()
    
    data := <-channel

But you could also, for example, keep sending data and send it to as many consumers as you like..

    go func() {
        for { // Infinite loop:
            // snip
            channel1 <- data;
            channel2 <- data;
            channel3 <- data;
        }
    }()