Comment by phplovesong
Comment by phplovesong a day ago
I wish Zig had not done async/await. CPS (like you have in Go) is way, way better, and is lower level, making it possible to do you own "async/await" if you really want to.
Comment by phplovesong a day ago
I wish Zig had not done async/await. CPS (like you have in Go) is way, way better, and is lower level, making it possible to do you own "async/await" if you really want to.
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?
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.
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();
channel := make(chan int);
go func() {
// snip
channel <- data;
}()
data := <-channel
go func() {
for { // Infinite loop:
// snip
channel1 <- data;
channel2 <- data;
channel3 <- data;
}
}()
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).