I've got that stuff all figured out, should have some interesting updates for everyone over the next 2-3 months. Been redoing I/O from the ground up - mostly standard library work.

Is it really that important though, to have async/await? I mean, do Zig developers actually need it?

Funny, this is the central question of the talk that I am working on for Systems Distributed in Amsterdam next week.

Hoping they make the talks available afterwards on YouTube or somewhere.

Its the feature I’m waiting for before I start a project I’ve wanted to do for a while in Zig.

I’d say it’s really important to get async nailed before 1.0, because it’s potentially one of the biggest killer features for many projects.

Zigs async isn’t just about I/O, I’ve found the feature useful in hardware simulation code as well.

Do developers actually need anything more than assembly?

When choosing a new language (and ecosystem) in which to invest my time, I'm more likely to pick one that's versatile than one that struggles outside of a niche. Even with a background in processes, threads, manual event loops and callbacks, I find that higher level concurrency features make my life easier in enough different situations that first-class support for them is now fairly high on my shopping list.

Do I actually need a language with something resembling coroutines? No; I got by for decades with C and C++. But I want it. It makes me more productive and helps me to keep my code simpler, both of which are valuable to me. These days, I have found myself walking away from languages for being weak in this area.

Now imagine Zig with channels and go routines...

Keeping Zig simple and close to C seems the most beneficial. Something that can be used everywhere that C is currently used. Otherwise it moves from systems programming language into applications programming.

IMO there are plenty of cases where you don't need to sqeeze every little drop of performance by going all in with epoll/io_uring directly, but you still want to handle 10k+ concurrent connections more effectively than with threads

epoll combined with a thread pool

I don't know about others, but it is for me. I guess it depends on what you're working on.

Reading the link, it seems to me async is never coming back or at least not till 2028.

I don't understand how you reached this conclusion.

Nothing is decided for sure, but the plan is most likely to re-introduce stackless coroutines as a set of lower-level primitives [0], and support implementing the planned `std.Io` abstraction [1] using them. The usage isn't quite as "pretty" as our old async/await syntax, but this approach sidesteps a lot of design problems, allows applications to seamlessly switching between different async implementations (e.g. stackless vs stackful), and simplifies the eventual language specification.

It's true that we're not doing this work right now, but that doesn't mean async is "never coming back", nor that you'll be waiting "till 2028".

[0]: https://github.com/ziglang/zig/issues/23446 [1]: https://github.com/ziglang/zig/blob/async-await-demo/lib/std...

Sure, I was just tempering expectations. In large project there are always tons of competing priorities competing. Considering many things needed before async and not all of them may be complete before other important work like incremental compilation, new backends etc. It maybe a while to see async.