4 ms·
This is a standard library change, not a syntax change I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing bec
by audunw 1y ago
This is a standard library change, not a syntax change
I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right.
As the PR description mentions: “This is part of a series of changes leading up to "I/O as an Interface" and Async/Await Resurrection.”
So this work is partially related to getting async/await right. And getting IO right is a very important part of that.
I think it’s a good idea for Zig to try to avoid a Python 3 situation after they reach 1.0. The project seems fairly focused to me, but they’re trying to solve some difficult problems. And they spend more time working on the compiler and compiler infrastructure than other languages, which is also good. Working on their own backend is actually critical for the language itself, because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM
- dosshell 1y ago>> because part of what’s holding Zig back from doing async right is limitations and flaws in LLVM this was interesting! Do you have a link or something to be able to read about it?
- audunw 1y agoMuch of the discussion is buried in the various GitHub issues related to async. I found something of a summary in this Reddit comment https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbta/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button https://www.reddit.com/r/Zig/comments/1d66gtp/comment/l6umbt...
- throwawaymaths 1y agoiirc the llvm async operation does heap allocations?
- travisgriggs 1y ago> I think the main big thing that’s left for 1.0 is to resurrect async/await.. and that’s a huge thing because arguably very few if any language has gotten that truly right. Interesting. I like Zig. I dabble periodically. I’m hoping that maturity and our next generation ag tech device in a few years might intersect. Throwing another colored function debacle in a language, replete with yet another round of the familiar but defined slightly differently keywords, would be a big turn off for me. I don’t even know if Grand Central Dispatch counts, but it—and of course Elixir/Erlang—are the only two “on beyond closures/callbacks” asynch system I’ve found worked well.
- messe 1y agoAs far as I know, Zig still wants their implementation of async to avoid function colouring.
- stratts 1y agoMy understanding is that the current plans are to implement async in userspace, as part of a broader IO overhaul. This would involve removing async/await as keywords from the language.
- throwawaymaths 1y agopart of function coloring is "not being trivially resolvable". in this case the function coloring boundary is trivially resolvable. const pick_a_global_io = ...; fn needs_io(io:IO) void {...} fn doesnt_take_io() void { needs_io(pick_a_global_io); } easy peasy. you've resolved the coloring boundary. now, if you want to be a library writer, yeah, you have to color your functions if you don't want to be an asshole, but for the 95% use case this is not function coloring.