11–20 of 62 posts
Why Async, especially considering Zig intends to be something like a High Level "portable Assembly"?
"A delayed game is eventually good, but a rushed game is forever bad." - Shigeru Miyamoto
The same goes for features. I'd rather Zig have a delayed/good async next year and forever after, instead of a rushed/bad async right this moment and forever after.
Why Async, especially considering Zig intends to be something like a High Level "portable Assembly"?
Zig's async implementation is the best of any languages, because you can run them without an event loop and in that case they will be simply synchronous. This completely eliminates the function coloring problem.
Why Async, especially considering Zig intends to be something like a High Level "portable Assembly"?
Zig's async, like Lua's, lets people write libraries that are generic over async-ness by default. "dump my registers and jump to another stack" is also a legitimate move in assembly (though that's not how this implementation actually works).
Why Async, especially considering Zig intends to be something like a High Level "portable Assembly"?
Zig's async implementation is the best of any languages, because you can run them without an event loop and in that case they will be simply synchronous. This completely eliminates the function coloring problem.
Why Async, especially considering Zig intends to be something like a High Level "portable Assembly"?
Waiting for IO is never cool. Also, zig's version of async is pretty low level and still obeys the no hidden control flow mantra (at least how it was implemented until 0.9.0).
Seems like Rust is still working on this area with the controversial keyword generics
Earlier quoted context omitted.
Zig's async implementation is the best of any languages, because you can run them without an event loop and in that case they will be simply synchronous. This completely eliminates the function coloring problem.
Usually the coloring problem IME goes the other way: you want to run a synchronous/blocking function in an async context. How does Zig deal with that?
Earlier quoted context omitted.
Zig's async implementation is the best of any languages, because you can run them without an event loop and in that case they will be simply synchronous. This completely eliminates the function coloring problem.
Does that mean the return types are the same when you use async or not on the same function?
Earlier quoted context omitted.
Waiting for IO is never cool. Also, zig's version of async is pretty low level and still obeys the no hidden control flow mantra (at least how it was implemented until 0.9.0).
How was it implemented in the past? Is there any overview of the design iterations Zig has gone through? Seems like Rust is still working on this area with the controversial keyword generics
Earlier quoted context omitted.
Does that mean the return types are the same when you use async or not on the same function?
No, there still are sync and async versions of functions. Zig just implicitly chooses which version to run and implicitly inserts await points. There's still a runtime and event loop if you use async. It's an async like in any language, but it relies on compiler magic instead of having locally explicit syntax.