3 ms·
> 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
by 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.