3 ms·
Check out the Q&A in this video to hear it from the man himself, it's the first question: https://www.youtube.com/watch?v=5eL_LcxwwHg https://www.youtube.com/wa
by TwentyPosts 3y ago
Check out the Q&A in this video to hear it from the man himself, it's the first question: https://www.youtube.com/watch?v=5eL_LcxwwHg https://www.youtube.com/watch?v=5eL_LcxwwHg
The tl;dr is: "The previous async approach ended up not working, and had to be removed. It's currently an incredibly hard problem with no clear rodemap. The plan is to get there eventually."
- dom96 3y agoAny more details about why the previous async approach ended up not working? and/or what that approach even was?
- TwentyPosts 3y agoI have never used it directly, take what I say with a grain of salt. As far as I know at least part of the idea was to eliminate the function coloring problem by letting the compiler do some nifty compile-time deductions. This had some issues (I don't know if this is still planned, it seems like the kind of thing that should not work in practice). Additionally, there were all sorts of hard technical issues with LLVM, debugging, etc. I recommend checking the issue tracker, eg. https://github.com/ziglang/zig/issues/6025 https://github.com/ziglang/zig/issues/6025 I personally don't understand the domain well enough at all, but honestly, I feel like (if possible) Zig should try to double down on its allocator approach. Instead of trying to use some compile-time deduction magic explicitly pass around an "async runtime/executor" struct which you explicitly have to interact with. Why not?