I wish zig could be enabled for godot.
Zig: Upcoming release postponed two more weeks and lacks async functions
21–30 of 62 posts
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#22I have yet to try Zig, but I approve of the idea of taking extra time and reducing scope to make sure that what you do ship is solid, especially in something like a programming language that may end up being a foundational piece of many other projects.
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#23Earlier 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?
No, async functions still return an async Frame (the semantic equivalent of a Rust Future) which evaluates to the result, rather than the result itself. Zig's "colorless async" description comes from the implicit infectiousness by default rather than colors not "being there":
A function which contains a suspend point becomes implicitly async. An await is implicitly a suspend until the Frame completes, so it also makes the caller's function async. Calling a async function without the `async` keyword is implicitly `await (async f(args))` so same deal.
You ended up not needing to know if `f()` is async or not when you call it ("effectively colorless"). If it is, it just makes you async and bubbles up until the sync boundary (an `async f()` call, `main()`, or an `export fn` C API).
Zig's stdlib could handle the main() case and spin up an event loop if you requested via `io_mode = .evented`. Some stdlib stuff like net/fs would then use the event loop while others like os/Thread would stay the same if you still wanted to do sync stuff.
This was the common case, but async is a lang construct not an stdlib construct so it works for all targets. For example, you could use it in wasm, the kernel, etc. You would just need to write your own starting / scheduling of the frames, known generically as an "event loop".
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#24I wish zig could be enabled for godot.
What do you mean by "enabled"? If you want to use Zig with Godot, you can! Just use GDExtension [0].
[0] https://docs.godotengine.org/en/stable/tutorials/scripting/g...
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#25Why 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).
How the heck would that even work...
In C#, they implement Await/Async by converting the function into a Class, just like when you use 'yield return'. Control flow is all over the place.
Zig is so strict about "no hidden control flow" that you can't even have destructors (code which runs when a variable goes out of scope)
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#26I really appreciate the honesty. It is not the end of the world to delay a highly anticipated feature, especially when the delay was a consequence of prioritizing the long-term stability of the codebase over the promised delivery date.
There are costs to not shipping a feature you meant to ship. So we first get a bit of sunk cost fallacy, trying to stretch to meet the goal, then if we pull back we have to make sure the feature is either completely toggled off or reverted. And then you have to fix the docs, which is never a fast process. It always takes longer wall-clock time to do the grunt tasks than strictly necessary to perform the steps.
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#27Earlier 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?
They have await keyword. This is noop in sync mode
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#28Earlier quoted context omitted.
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
https://kristoff.it/blog/zig-colorblind-async-await/
I can't tell from the examples. Does Zig's async support closures or is it strictly out of order execution?
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#29Earlier 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 the heck would that even work... In C#, they implement Await/Async by converting the function into a Class, just like when you use 'yield return'. Control flow is all over the place. Zig is so strict about "no hidden control flow" that you can't even have destructors (code which runs when a variable goes out of scope)
Huh? Lots of language do not have guaranteed to be called at a specific time “destructors”.
Additionally, zig provides this functionality with defer and errdefer, giving you the ability to explicitly call a function at the end of scope.
Re: Zig: Upcoming release postponed two more weeks and lacks async functions
#30Earlier quoted context omitted.
https://kristoff.it/blog/zig-colorblind-async-await/
I can't tell from the examples. Does Zig's async support closures or is it strictly out of order execution?
Zig does not have closures, and probably never will barring someone coming up with a nice, no hidden flow idea for captures.