Skip to content

Comment on Asynchronous clean-upparent

Comments

I know that Zig is quite different from Rust and it is less mature, but I do wonder how its async compares.

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

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."

Any more details about why the previous async approach ended up not working? and/or what that approach even was?

I 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

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?

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.