I am saddened to hear that. To me, ZIO is one of the solid foundations for writing high-performance services in Zig. I hope that community contributions will make you change your mind.
3 Likes
It’s extremely likely that I will continue to support it, because I’m kind of hooked. I never expected it would turn this way, but I enjoy working on it a lot. A now it’s at the point of competing with mature tools like Tokio. It would he stupid to abandon that. At the same time, I’m hesitant using Zig for new projects, until see better direction for Zig.
5 Likes
On my side I am completely hooked to LLM coding, and to Zig. I really like reading LLM written Zig code. I tell the LLM to optimize for my understanding, so the code is verbose and well commented. I focus my work on research topics just outside my understanding level, improving and completing what I worked on before in my career, mostly physics/robotics simulators, deep learning, and character animation systems for games. My hobby project has now hundreds of thousands of lines easy to read zig code, with no dependency on anything else than the compiler. I try to see the positive side of all this, and just have fun without worrying too much. I think Andrew should take his time, making zig perfect in the long term, so we can continue having fun with it, with or without LLMs.
2 Likes
Yep this was, and still is the plan.
To those in this thread who feel like it’s taking too long and that prefer to move to a different language with or without LLM assistance, I wish the best and I sincerely hope that your time in the Zig community taught you something valuable about software that will help you create better software going forward, whatever your path might be.
I personally would be extremely unhappy if in an alternative reality a genie showed me that by rushing ahead in some form of “response” to LLMs (i.e. if we did what some of the people here would like us to do), we ended up never discovering the new Io interface (most importantly asynchrony vs concurrency), or we never invested in incremental compilation, or any of the other accepted proposals, especially the moonshot ones, like stack overflow safety, or the filzig one.
Our perspective on this stuff is that everything that helps human developers will also work just as well with LLMs. Just think about incremental for example: everybody has to gain from instant rebuilds, both LLM-users, non-users, and everything in-between. And if you think that if we just vibecoded this stuff, it would happen faster, let me remind you that so far the best attempt at that was a 4x build speed improvement from Jarred which also introduced non-deterministic false positive build errors which, in case it’s not clear, is not even remotely good enough.
That said, different people have different priorities so nothing wrong in walking a bit of the path together and then parting ways, be it for a while or forever.
15 Likes
This is the most important point on the subject IMO, and it is totally in line with my own experience. Anything that improves the readability or dev experience of a codebase for a human being also helps LLMs to read and maintain that codebase. I haven’t found a single counter-example. All the superb design taste and language/tooling simplicity in Zig are great for coding agents too, and I hope the Zig project just continues doing what it’s doing. (FWIW std.Io is my favorite addition to the std lib of all).
This is why those new “AI-optimized” programming languages never got anywhere. Languages optimized for humans are already optimized for AI. This insight is also a great cure for the “existential dread” that many, including me, felt earlier this year. It’s a comforting thought that the skills and design taste we all developed over our careers are not suddenly irrelevant; things like good naming, separation of concerns, and avoiding premature abstraction are important whether you are using AI or not.
3 Likes
@zelda-rageux actually there is one thing to say. This is not offensive. Please understand. I really need to convince this to you.
Programming language is a systematically written language. It’s not an average consumer level LLM driven and time to time changing language. Humans have the mental capacity to solve problems design things. We have been doing this for about millions of years. Still things created by our ancestors exist today. Most of them are still functional. Genetically we are designed for this. But AI cannot do this.
AI target for results. Humans target for reliable results.
I’m just a 30 year old guy. I have also been coding since my 14s. But I only learned Bash, C and Python. I did not wanted to fall for Go/Rust. It was my gut feeling. And I’m happy about that. Now I know there are more people like me. During past 3 months I learned Zig and wrote production level code. It’s stable. No memory leaks. Code is readable. Everything is running smooth. Now Zig is my first class citizen. @zelda-rageux you are 59 years old. “Where were you?”
Everything we see today is driven by some kind of hype:
- Go is a hype driven by Google search engine result manipulation during early 2015s. It was planned. When you search google how to do something, first thing appear is a garbage Go project to convince you to use Go over other languages. See for yourself Read History Section of Tiobe Index Wiki to learn how Google can change the narrative.
- Rust is the other one; Linux announced Rust is the biggest revolution in L.Kernel History. lol. That’s how they marketed Rust. “It’s a marketing trick”
When I query the same thing using duckduckgo or other search engines, I get un-manipulated results. LLMS may know very much about Rust. Because “Marketing triggered it’s audiance towards Go/Rust” and LLMS trained using the input of that audiance. Even if LLMS learn about Zig 100%, I don’t think LLMS want to make reliable things.
2 Likes
Human UX with a language is similar to an AI’s UX. There are some things that are just smart decisions and benefit all thinking creatures, like good naming. Regardless of which planet your constituent carbon atoms evolved from, local reasoning remains important. But things like Rust’s borrow checker are perfectly shaped for AI while not necessarily perfect for (all) humans. They can read and write faster, longer, and cheaper. They’re better at following game rules and checking tests. Humans have better state/world models, but limited time and memory. Also read/write-ability, overuse of <>!?#$ almost doesn’t matter for them. Ultimately the choice depends on whether you want the AI to help you, or you want to help the AI.
AI-optimized languages will get somewhere eventually, just not overnight. The languages have to 1. be ready first, and 2. AI needs world models to develop more autonomy, otherwise it needs to use human languages when working in tandem with them.
Don’t waste your time supporting so many different systems and architectures. It’s completely pointless.
Let’s just get 1.0 released as soon as possible.
Let’s focus on the most important thing first: getting 1.0 released. Then we can expand support for different systems and hardware architectures.
why architecture should be dropped ?
how do you make sure you don’t get stuck in a local optimum that works on some arch but not others ?
Like the ongoing on SpirV could be the great defining feature of Zig in two years, as GPU programming continues to become more and more important
7 Likes
Let’s talk about bread.
While its a good analogy please remember that in the 1960s there were about 200.000 bakers employed in Germany while in 2025 its about 45.000. Realistically most of us will have adjacent jobs and only bake bread as a hobby with no compensation (open source).
Since programming is really fun there will probably be quite a lot of competition for the remaining actually compensated programming jobs. After all why are all of you spending time on an independently hosted internet forum for a niche programming language? Because we love doing that.
3 Likes
Adding my personal thoughts: 
I think creating a stable programming language is a long-term project, so I’m fine with Zig taking more time if it means getting things right.
From my experience, AI/LLMs can definitely make development much faster, but I also think there is a downside, especially for a project like a core programming language. If a lot of code is generated quickly, reviewers have much more code to understand and maintain. Sometimes it’s also difficult to understand why something was implemented in a particular way. Over time, I think this can become frustrating for core contributors and may lead to burnout. More chance bad code written and later issue to maintain it. 
So personally, I would prefer Zig to move forward consistently rather than trying to move extremely fast with AI/LLMs. A healthy community and a stable language are more important to me than development speed. I believe slow and steady wins in the end.
I don’t think that means we shouldn’t use AI. It can be useful for things like:
- initial research and exploring ideas
- creating a proof of concept
- trying different approaches
- finding potential security issues
- generating tests or helping investigate bugs
For the actual core development, I think it’s fine if humans remain more involved and the project doesn’t try to maximize AI-generated code.
I also think commercial adoption will play a big role in growing the Zig ecosystem. If more commercial software is built with Zig and more companies start hiring Zig developers, I think more people will naturally become interested in learning it. Then, as more developers use it, the ecosystem, libraries, tooling, documentation, and community will slowly grow as well.
And there is an interesting opportunity with AI later.
Most end users will probably use AI/LLMs to write Zig code anyway. If Zig has a stable language, good documentation, secure examples, and established best practices, the community could eventually provide good RAG/MCP resources for Zig 1.0+.
Then AI could be guided toward generating Zig code based on those patterns instead of just generating code that happens to compile.
So for me, it’s less about AI vs. no AI. It’s more about building a solid foundation first and letting the ecosystem grow steadily.
4 Likes
Funny, just earlier today I had to explain to someone that wanted to use Odin on an ESP32, that Odin only supports 64bit architectures.
The fact that Zig runs on basically anything is a huge boon to the language. It gives it a leg up on alternate languages like Odin, and even Rust. When Linux started adopting rust, one of the issues raised (I believe) was that it limited the architectures that would be supported going forward.
And if Zig hopes to one day supplant C (which I believe is one of the stated goals), then it has to run anywhere C does.
5 Likes