4 ms·
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 implemente
by laserbeam 3y ago
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).
- chubot 3y agoHow 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
- somethingor 3y agohttps://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/
- hinkley 3y agoI can't tell from the examples. Does Zig's async support closures or is it strictly out of order execution?
- wredue 3y agoZig does not have closures, and probably never will barring someone coming up with a nice, no hidden flow idea for captures.
- laserbeam 3y agoIt's similar to manual control over the current stack. You pause execution, you dump your current stack onto the heap, and restore it later. Control over concurrency, similar to out of order execution. I'm describing it conceptually but I assume the implementation can be/was smarter/faster. I don't think closures have anything to do with it. There was also some debate about how cancelation of an awaitable function built with those primitives would work. I don't think there was a great answer for that yet.
- Dwedit 3y agoHow 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)
- wredue 3y agoHuh? 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.
- DaiPlusPlus 3y ago> Lots of language do not have guaranteed to be called at a specific time “destructors”. Those tend to be GC languages though, where deterministic execution is not a hard requirement.
- wredue 3y agoSure, but this is also what defer is for. There isn’t implicitly called destructors because the languages mantra is “no hidden control flow”. RAII et semantics is almost entirely hidden control flow that you just have to “know”. Lots of people hate when they need to “just know” things to fully parse the code they’re reading. You’re free to dislike those decisions, of course. Personally, I like the target of no hidden flow.
- bsder 3y agoI have a love/hate with this. The big problem with defer/errdefer is that I have no way to mark a function as "This function always needs a defer after it and the compiler needs to yell at me if it doesn't exist." It's also sometimes really hard to scope your defer/errdefer correctly. You may have to twist your code inside out because defer/errdefer ends at a block scope while your variable may not (via: "break :blk varname;"). This all bites so hard for things like reference counting. The bugs ... the bugs ... <mumbles huddled up in corner>