A new Zig SHOWTIME episode was scheduled for July 2nd 2025 to talk about the Zig roadmap for 2026 with Andrew.
For more info and precise airing times see https://zig.show/episodes/41/
EDIT: here’s the VOD
37 Likes
The day after my birthday, what a treat
7 Likes
Are you Canada?
8 Likes
“Reviving async await” will be a big marketing win … there remains a lot of zig curious on the sidelines who still think it’s impossible to have concurrency without it
Meanwhile, in app dev world, we have made significant gains using epoll/kqueue or libxev without it
It’s a big win for wider zig adoption
As long as we all stay true to the zen of zig, and remain a welcoming community eager to ease new people into the fold, we should survive the coming flood of new adopters.
Can’t stress this last point enough. When languages take off in popularity, this can be both heady as well as challenging in its own way. We are all going to have to be extra excellent and accommodating.
There is a whole vast pile of untapped talent about to join us, learn from us, and in turn teach us new ideas.
12 Likes
Jul 1 birthdays, unite!
is the async/await gonna be like tardy?
If Zig team will standartize the IO interface, it will be similar.
Dont take my word for it, hopefully we will get more details tomorrow, on what path they chose to follow.
I’m too excited, they might add std.async.Runtime or something, and maybe std.async.Io or std.io.AsyncIo? Zig does nothing in your back (unlike some people, C ahem) so I thought they would do something like. “You want async, you’ll need a runtime to handle jobs/frames running/pausing… here is an std interface and an implementaion and do whatever you like with them!”
for a language with no multiline comments or python-style multiline strings, checking the function’s type and guessing the context feels odd, that’s why I brought up tardy, it felt like I was using std
so, I do want them to consider something like it. I feel like it would be a loss if it gets dismessed
There was a lot of discussion, if IO interface will land, it will be a lot like tardy (used like std.mem.Allocator, passed on where needed).
Andrew stream:
Just one of MANY discussions:
2 Likes
To what extent though, would implementation of async/await push back the 1.0 milestone? In my opinion, it’s a feature that’s nice to have but goes beyond Zig’s mission of being a C replacement. If the effort required turns out to be larger than expected then it’s better to defer it. To use a football analogy, the team should be ready to punt the ball if they can’t make enough ground in three downs.
Fair call, but from what I’ve read on the issue tracker, they have a new & better way of sorting it out, so dont see it being a delay.
Wait and see what they say at the showtime
The path to 1.0 isn’t a straight line - it’s more a zig zag (see what I did there)
3 Likes
Keep it simple, keep it stable, and documentation, would be wishes for Zig 2026+.
Async feels like a distraction in complexity, but I can appreciate wanting to solve that complexity earlier rather than later. I think what helped Java back in the good old days, was having a bullet proof JLS (Java Language Specification). Every nuance of language and API design could be understood from a close read of the JLS. It was only a couple pages, but the deeper I got into the language and JVM, the more valuable it became, especially that is was stable for 10+ years?
As per the possible new io design, am I still catching up, but having state always passed around starts to get messy fast. I like an encapsulated API that knows how to manage it’s own state. The complexity here seems to be driven by lack of a global allocator, and that starts the trickle of passing context/state around.
We know that Readability of code is difficult to balance with Explicitness goal. But when I try to read logic, and every single line starts with ‘try’, and every first parameter is an allocator, it starts to cloud the intent. We know pretty much every line of code can fail. Here I see the benefit of unchecked RuntineExceptions. Currently I find myself writing allocation free code, which is quite fun so far.
Going forwards I see Zig splitting into:
ZigFat - The commercially sponsored scope creep version, trying to turn Zig into Go/Java. Modules, large stdlib, runtime, complex concurrency/async, i18n, etc
ZigTiny - The lightweight spiritual successor of C focused on embedded and keeping it close to the metal.
Maybe accepting this inevitability would allow both languages to be developed under a single foundation from the start.
Anyway, having shared coffee ramblings, I’ll take a breath to say I love Zig, and thank-you all for such an fresh fun language to work with.
PS Are the videos mirrored outside of the google cage?
1 Like
Uh, that’s not the purpose of a road map. People want to know how much longer before they reach a destination. They don’t want a promise of more zigzag ahead.
How do we watch?
Apparently they are having trouble with the connection and it is postponed for tomorrow.
3 Likes
There’s no link to the stream
1 Like
Speaking for myself, I want to see Zig declared 1.0 when it’s ready. Definitely not before.
I’m well aware of the underlying pressure here, and it needs to be accommodated. It’s quite possible to start standardizing and stabilizing parts of the language, as soon as right now. Semver is quite, well, binary about this: if it starts with 0 all bets are off, and if it starts with 1 there are significant guarantees involved.
But semver isn’t a law of nature, and there’s nothing preventing a more gradual approach. I bet a process like this would be useful on its own terms, as well: identifying what’s considered finished, and what isn’t, is a good guide for what’s left to do.
1.0 doesn’t mean finished, either, it’s hard to think of a language which hasn’t introduced significant post-1.0 features. But 1.0 would be kinda meaningless if it allowed for breaking changes to something as pervasive as IO.
I’m not in a position to even say if Zig is ready to begin a process like this, to be clear. But maybe: it seems nearly certain that the while loop syntax will never receive a backward-incompatible change, for one example.
4 Likes
Releasing something “when it’s ready” is a privilege reserved to teams who have succeeded spectacularly. Zig hasn’t gotten there yet. Hitting the 1.0 milestone is important since it’ll bring in more financial resources.
This seems exactly backward to me. Zig isn’t “unicorn driven development”, so it succeeds by getting it right.
Nor do I see a bright line from flipping the 1.0 switch to Zig receiving more financial resources. I’m sure the Foundation can always make good use of additional funds, but I expect that if they felt an acute need for more they could probably just get it.
If “financial resources” means more Zig jobs, well, maybe. Plenty of post-1.0 languages where the job market is basically a wasteland. Best way for Zig to avoid that is to not kick a half-baked 1.0 out the door.
12 Likes
Zig doesn’t need async/await to be fully baked, that’s the point I’m trying to make.
3 Likes