Having experiences in Rust, I have observed that a not-well-integrated async/await support can cause issues. I think it’s not just me who feels like async in Rust really brings a lot of complexity to the programmer. I made a post two years ago on issues where (in my opinion) Rust has made decisions which cause friction for the programmer.
I would like to see Zig doing async in a way that feels right and integrates well with the rest of the language.
Now whether to reach that goal it’s wiser to defer async/await or to do it ASAP, I’m not sure. But I think making backward-compatibility promises too quickly (whether you call it 1.0 or not) can endanger that goal.
Sure, I’m looking at it as “major breaking changes to everything involving IO”, not async per se (and the current work involves full-on coroutines, which are much more interesting than the frame / state machine transform approach, at least to me).
It’s better if that happens before 1.0 rather than after.
I tried to watch the live stream and actually got a playback from the failed attempt yesterday. Or @kristoff said the exact same thing today again, which I doubt was the case.
Looks like there are some technical problems again today (on Thursday, July 3rd)?
I would rather write C99 than ANSI. Languages are complete when no one wants to keep maintaining them. Even Ada has received some updates over the years.
I was more or less joking of course. I remember vividly my days as Delphi programmer in which every release there were bug fixes and these updates always introduced new bugs. Introducing generics took years to more or less stabilize (in production versions!).
I also remember they added the @ctz equivalent which produced 32 bit code in 64 bits compilations. The users were mainly bug-trackers I got the feeling.
That is what I call “not finished”.
BTW: I enjoyed the stream. Thanks Andrew! I am even contemplating a donation
Personally, I think that asyc/await always feels like a crook (?) for languages that don’t support multiple threads. It feels wrong somehow and I hope that someday someone comes up with a language which kind of generates asynchronous code automatically when appropriate, to make full use of the CPU when waiting for IO in other tasks.
Until then, I think it is a feature that I don’t expect/need in a low-level language like Zig.
IMHO the problem isn’t async/await itself, but that too much of it is happening under the hood via code transformation by the compiler and required runtime support.
Ideally, libraries should be agnostic to async runtime implementation details (e.g. whether it is implemented via POSIX-style threading, green-threading via stack switching, or stackless via a state-machine code-transformation, io_uring-style request/response ring buffers, or even plain old completion callbacks - or a mix of all of those), and that’s exactly what this new IO interface offers. Libraries are written against the IO interface, the runtime is injected by the library user.
I haven’t watched the video yet, so I don’t want to get into the weeds here, just to say this: parallelism and concurrency are not the same, and don’t substitute for each other. Async is a kind of serial control flow, threads are a mechanism for parallelism. Many interesting program models require both, like the typical libuv / libxev style event loop.
hello, I’m new here (waves) but not a newbie; been following Zig since its infancy and stoked to see all the progress in the past 2-3 years. I spend most of my time professionally in Go.
I just saw the release video and wanted to chime in to say that I think the async/await pattern in the pipeline is going to be brilliant. Being able to inject an IO implementation means you can have platform/hardware specific abstractions without affecting user code, and we still don’t incur a runtime penalty.
The ergonomics here are just great: wrap normal functions w/ async, then execute by calling await in a separate statement. I’m excited to track progress on this.
great work on the roadmap overall - the effort these past few years here are herculean and not unnoticed. Well done Andrew & team
Thanks for the demonstration. I am not done with the video, yet. But the switch labeling is awesome. Yesterday i was working with switches and needed a c-like switch fallthrough. Hacked some nested switches, but this makes it so much nicer.
But I think making backward-compatibility promises too quickly (whether you call it 
