# Zig Roadmap 2026 **URL:** \ **Category:** News\ **Created:** [June 30, 2025, 4:29pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750 "2025-06-30T16:29:22Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![kristoff](https://ziggit.dev/user_avatar/ziggit.dev/kristoff/32/9_2.png) [@kristoff](https://ziggit.dev/u/kristoff)\ **Post date:** [June 30, 2025, 4:29pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/1 "2025-06-30T16:29:22Z")
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/](https://zig.show/episodes/41/) EDIT: here’s the VOD [![](https://ziggit.dev/uploads/default/original/2X/9/91208d5bf13acf56f728959145544477037475c2.jpeg "Zig Roadmap 2026") ](https://www.youtube.com/watch?v=x3hOiOcbgeA) ---
**Author:** ![mattnite](https://ziggit.dev/user_avatar/ziggit.dev/mattnite/32/5666_2.png) [@mattnite](https://ziggit.dev/u/mattnite)\ **Post date:** [June 30, 2025, 4:31pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/2 "2025-06-30T16:31:00Z")
The day after my birthday, what a treat ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [June 30, 2025, 5:58pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/3 "2025-06-30T17:58:06Z")
Are you Canada? ---
**Author:** ![zigster](https://ziggit.dev/user_avatar/ziggit.dev/zigster/32/51_2.png) [@zigster](https://ziggit.dev/u/zigster)\ **Post date:** [June 30, 2025, 10:08pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/4 "2025-06-30T22:08:58Z")
“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. ---
**Author:** ![jmc](https://ziggit.dev/user_avatar/ziggit.dev/jmc/32/38_2.png) [@jmc](https://ziggit.dev/u/jmc)\ **Post date:** [June 30, 2025, 10:40pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/5 "2025-06-30T22:40:41Z")
Jul 1 birthdays, unite! ---
**Author:** ![IbrahimOuhamou](https://ziggit.dev/user_avatar/ziggit.dev/ibrahimouhamou/32/2344_2.png) [@IbrahimOuhamou](https://ziggit.dev/u/IbrahimOuhamou)\ **Post date:** [July 1, 2025, 2:22pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/7 "2025-07-01T14:22:02Z")
is the async/await gonna be like [tardy](https://github.com/tardy-org/tardy)? ---
**Author:** ![Bobvan](https://ziggit.dev/user_avatar/ziggit.dev/bobvan/32/5105_2.png) [@Bobvan](https://ziggit.dev/u/Bobvan)\ **Post date:** [July 1, 2025, 2:49pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/8 "2025-07-01T14:49:29Z")
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. ---
**Author:** ![IbrahimOuhamou](https://ziggit.dev/user_avatar/ziggit.dev/ibrahimouhamou/32/2344_2.png) [@IbrahimOuhamou](https://ziggit.dev/u/IbrahimOuhamou)\ **Post date:** [July 1, 2025, 3:17pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/9 "2025-07-01T15:17:42Z")
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 ---
**Author:** ![Bobvan](https://ziggit.dev/user_avatar/ziggit.dev/bobvan/32/5105_2.png) [@Bobvan](https://ziggit.dev/u/Bobvan)\ **Post date:** [July 1, 2025, 3:28pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/10 "2025-07-01T15:28:53Z")
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: [![](https://ziggit.dev/uploads/default/original/2X/2/2310298ec0a0c6de1972674d1dcc7b4a854074c8.jpeg ""Zig ⚡ Development⚡ Async/Await Resurrection" [March 28 - 2025]") ](https://www.youtube.com/watch?v=0kUvoU60pbc) Just one of MANY discussions: > [@The new \`Io\` abstraction](https://ziggit.dev/t/the-new-io-abstraction/9404): > > Beware, the following is a long-winded reflection on the current discussion on async and IO abstraction. There is no purpose to it but to organize my thoughts and comes from someone with limited understanding of what is being achieved. In his [last live stream](https://youtu.be/0kUvoU60pbc?feature=shared), Andrew K. shared his reflection (intention?) to start working on async/await again and started introducing a new concept: the IO interface. My understanding of it is this Io interface is an [inversion of control](https://en.wikipedia.org/wiki/Inversion_of_control). It’s an abstraction that … ---
**Author:** ![chung-leong](https://ziggit.dev/user_avatar/ziggit.dev/chung-leong/32/999_2.png) [@chung-leong](https://ziggit.dev/u/chung-leong)\ **Post date:** [July 1, 2025, 11:40pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/11 "2025-07-01T23:40:54Z")
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. ---
**Author:** ![zigster](https://ziggit.dev/user_avatar/ziggit.dev/zigster/32/51_2.png) [@zigster](https://ziggit.dev/u/zigster)\ **Post date:** [July 2, 2025, 3:17am UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/12 "2025-07-02T03:17:19Z")
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) ---
**Author:** ![whitehexagon](https://ziggit.dev/user_avatar/ziggit.dev/whitehexagon/32/5917_2.png) [@whitehexagon](https://ziggit.dev/u/whitehexagon)\ **Post date:** [July 2, 2025, 11:04am UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/13 "2025-07-02T11:04:41Z")
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? ---
**Author:** ![chung-leong](https://ziggit.dev/user_avatar/ziggit.dev/chung-leong/32/999_2.png) [@chung-leong](https://ziggit.dev/u/chung-leong)\ **Post date:** [July 2, 2025, 11:40am UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/14 "2025-07-02T11:40:25Z")
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. ---
**Author:** ![ath0006](https://ziggit.dev/letter_avatar_proxy/v4/letter/a/f6c823/32.png) [@ath0006](https://ziggit.dev/u/ath0006)\ **Post date:** [July 2, 2025, 4:09pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/15 "2025-07-02T16:09:33Z")
How do we watch? ---
**Author:** ![Luke](https://ziggit.dev/letter_avatar_proxy/v4/letter/l/7ab992/32.png) [@Luke](https://ziggit.dev/u/Luke)\ **Post date:** [July 2, 2025, 4:10pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/16 "2025-07-02T16:10:32Z")
Apparently they are having trouble with the connection and it is postponed for tomorrow. ---
**Author:** ![saurabh](https://ziggit.dev/user_avatar/ziggit.dev/saurabh/32/4623_2.png) [@saurabh](https://ziggit.dev/u/saurabh)\ **Post date:** [July 2, 2025, 4:24pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/17 "2025-07-02T16:24:37Z")
> [@kristoff](#): > > For more info and precise airing times see [Zig SHOWTIME](https://zig.show/episodes/41/) There’s no link to the stream ---
**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\ **Post date:** [July 2, 2025, 4:39pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/18 "2025-07-02T16:39:53Z")
> [@chung-leong](#): > > To what extent though, would implementation of async/await push back the 1.0 milestone? 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. ---
**Author:** ![chung-leong](https://ziggit.dev/user_avatar/ziggit.dev/chung-leong/32/999_2.png) [@chung-leong](https://ziggit.dev/u/chung-leong)\ **Post date:** [July 2, 2025, 7:38pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/19 "2025-07-02T19:38:40Z")
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. ---
**Author:** ![mnemnion](https://ziggit.dev/user_avatar/ziggit.dev/mnemnion/32/2478_2.png) [@mnemnion](https://ziggit.dev/u/mnemnion)\ **Post date:** [July 2, 2025, 8:02pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/20 "2025-07-02T20:02:26Z")
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. ---
**Author:** ![chung-leong](https://ziggit.dev/user_avatar/ziggit.dev/chung-leong/32/999_2.png) [@chung-leong](https://ziggit.dev/u/chung-leong)\ **Post date:** [July 2, 2025, 8:16pm UTC](https://ziggit.dev/t/zig-roadmap-2026/10750/21 "2025-07-02T20:16:45Z")
Zig doesn’t need async/await to be fully baked, that’s the point I’m trying to make. [Next page](https://ziggit.dev/t/zig-roadmap-2026/10750.md?page=2)