The Zig project is going nowhere
bytecode.news
bytecode.news
""" This is a site designed to serve as a center for information - and by "center," we mean center. ByteCode.News is a site fed from discord, slack, IRC, and here on the web, meaning to present a common information graph and a common set of services. """
From my quick skimming of the site it just looks like hundreds of AI articles. More than likely it's just an AI bot that generates articles after some threshold of engagement is reached on "discord, slack, IRC".
There are lots of Ads that are posted as if they are articles for example: https://bytecode.news/posts/2026/10/cheerpj-5-launches-java-...
The article itself is just an extremely odd hit piece against Zig, I'd even be guess this is a form of "rage/engagement bait".
Your article was much better, but I do wish the linked deep dive on CheerpJ was a bit meatier, it's more of an overview. A deeper dive about the trade offs of the implementation and other challenges you faced getting the JIT working inside WASM would certainly do well here.
Not true! It just means (realizing a) vision is more important to them than becoming popular. It's their choice to make.
It's also a choice many of us wish in hindsight our tool makers had made.
I don't necessarily agree with everything, but I appreciate that there's a strong vision.
The important question is when/whether it will hit 1.0 and what its commitment to stability looks like _afterwards_.
> Zig has been under development for more than a decade. It remains at version 0.x, without a firm date for a stable 1.0 release.
> A programming language is infrastructure. Developers write applications and libraries against its syntax, standard library, compiler, and build tooling, and those interfaces determine how much of the surrounding ecosystem remains usable from one release to the next. In Zig, they seem to be forever changing, with the authors nigh-obsessed about breakage.
> The maintainers have a roadmap to 1.0, but that gives developers no meaningful indication of when they can expect the interfaces they depend on to stop changing. It may well take another decade.
If your "inherently unstable phase" is going to last multiple decades, you're not in a phase at all. You're just unstable.
If LLM are as good as people say why care about unstable API the LLM can help rewrite and fix it withing like 60 min.
Doesn't mean much.
The point about constant compatibility breakage is the only valid one, but users are naturally self-selecting on that. I knew what I was getting into when I chose Zig. The upside is that the language isn't getting saddled by poor early designs (the "Writergate" breakage was a huge design improvement, as is the new Io interface). Also, it goes without saying that LLMs have dramatically reduced the cost of dealing with breaking changes, and the core team isn't going to stop you from using it.
Basically I feel like this author is trying to do a newspaper-style complaint, an opinion column, making "news" where there isn't really any. I don't think a project as small, mostly-volunteer-driven and friendly as Zig deserves that kind of treatment.
In relation to that, you obviously shouldn't just break stuff all the time (though I believe you reserve the right to do so before v1.0), but developers can also be so afraid of increasing the major version, that they just never do...
https://tom.preston-werner.com/2022/05/23/major-version-numb...
Even less so, in AI driven development age, that the Zig community is notoriously against.
Interesting language for the last century, between Modula-2, Object Pascal, C, C++ and co.
In 2026, less Interesting.
Maybe not unavoidable product, but zig has a vision, do not need to go different direction or make product immediately or die
Thankful for the Hashimoto support of both organizations' financial sources: Zig Software Foundation and Ghostty via Hack Club. Thus both projects have external accountability. Hopefully that can help long term viability issues and alleviate the projects' social and financial pressures, as well as guide the projects technological and management choices. If that scaffolding didn't exist, I might not have chosen the platform.
You are saying they Zig is uninteresting because they don't want to pander to the current fads?
Let them cook. Perhaps they want to work on the core language for now, and maybe in 2-3 years time they can focus on the framework.
Or maybe they don't care about being popular. A passion project that is being worked on for a small group's enjoyment can still be interesting.
Followed by being embraced by the scientific community like CERN and Fermilab, for build tools and scripting C++ and Fortran libraries, before taking off with AI.
I do wish there was a little less drama involved with Zig. Seems to be the curse of programming languages.
I also wish this article had a more... human touch. Not because of the phrasing etc, it just repeats itself a lot and a quick steer for brevity would have gone a long way.
I'm on the record as not a fan of Zig's management or choices, but this is among the many statements I disagree with in this article. The Zig team is writing (among other things) a compiler. If you don't want to become a compiler engineer, the maintainers are perfectly within their rights to decline to review your code or work with you further.
It's the other side of this that I take issue with. There are plenty of people who do want to become compiler engineers who see LLMs as a way of accelerating understanding by way of having a very well-informed (if not sometimes incorrect) chatbot be able to answer your questions and indulge your curiosity. IMO, it's these people that are the most let down by Zig's LLM policy.
It’s fine for them to just be.
(python 2 to python 3 migration would have been less of an issue now as well)
> Its contribution policy excludes otherwise legitimate engineering workflows. [...] The recurring theme is that Zig's maintainers appear more interested in enforcing their vision of how software should be developed than making Zig a practical tool for people who want to build software.
I think a reasonable read of Zig's comments on LLM contributions is the volume and quality of human contributions is sufficient to sustain the project, and trying to accept LLM contribution creates more work than solutions.
And the author conflates contribution policy with downstream use of AI. Users are free to adopt all the AI tools they want on a Zig codebase. It is not true that, for users, "certain tools which might make it easier are unacceptable".
I for one don't personally agree with a bunch of Zig's choices (not bets that I'm interested in), but think most or all are reasonable in the space of possible trade-offs.
It's more a toy of a small community of like-minded developers than a product for general consumption.
When Bun switched and they responded as they did the project confirmed that they aren't interested in serving the open market for developers, they're only interested in building something for themselves. Which is fine so long as all you're producing is the compiler; because all users, even those in their in-group, are subject to the stability problems with the language.
> The post criticized Bun's engineering practices, management, development culture, and business decisions. It described the foundation as relieved that the relationship was over and treated Bun as a liability (a term the Zig project seems particularly fond of when justifying its caprices). And all this in response to a project that had spent years using Zig, publicly promoting it, contributing to its ecosystem, and donating substantial amounts of money to its development.
They may as well have made their repos private and put up a notice on their website stating that they aren't interested in having users, please kindly withhold further inquiries.
Is it 1.0 yet?
The whole point of not being stable yet is so that you can try things out and see what actually makes sense before committing to it for all time.
(Counterpoint: C++, JavaScript xD)
I guess it has been like 10 years at this point though.
The way I read it, the post seems to argue they have enough users already to seriously consider cutting the first stable release.
That's why ISO is committee-based (democratic), despite the issues and slower speed, that process is better suited to
You can always make a fork of Zig called "Zack"....
Fayten makes a good point here https://news.ycombinator.com/item?id=50452445 About this article is 100% clickbait and 0 substance
Master Foo, who gains more merit? He who writes ten thousand lines?
Or he who, recognizing the emptiness of the endeavour, writes zero?
So the complaints are: 1) that a 0.x versioned language which itself says is unstable and will break things for the sake of future quality, is breaking stuff? Shocking. Unbelievable.
2) they moved to codeberg. I think it absolutely is fair to say a project is going nowhere because they went from one git forge to another. It's a big migration for end users after all, you have to set a new remote for your origin
3) they do not use github sponsor anymore. Wonder if this is because they moved to codeberg. Unsure.
4) they wish for contributors to be engaged with the project and to stick long term.
5) they make "sweeping statements" on the quality of AI. Nothing I say here will convince you of anything unless you already agree with me, so I will spare my time and just say that given the point of view here is that AI is actually better than what Zig contributors think it is, and Zig contributors target version bump documentation breaking changes for humans, wouldn't this also directly clash with your idea that breaking changes take up a substantial amount of work for users of Zig? It's one or the other
This goes alongside "the language doesn't own its users" - a claim so ridiculous, the authors themselves have said plenty of times that, for example, if you wish to use AI to develop zig, you can, just not in the compiler project. What have they done which would make you think anyone at ZSF wants control over what you do and how you do it?
Overall I feel like this is complaining for the sake of complaining. I am also willingly going to ignore the blatant AI writing style (I'm sure that's just the way OP writes though) and the site which I feel like I can confidently say with which model and what effort level it was generated.
Do better
Aside from the LLM flavour of the article, there seems to be a weird bitterness here, and a blind spot regarding both the reality of programming languages and their development generally, and also the clearly communicated reasons for the state Zig is in or the stances officially held. Compare the long development time of Java, taking nearly 20 years to reach Java 8 (which I think it's fair to say is a reasonable point where most of the language, library, and tooling had matured) and that still being supported more than a decade later (at least with OpenJDK), and I know even older versions of Java are still kicking around (a friend told me this year that their company had finally managed to migrate from Java 5 to Java 21, which had taken over years of work to update millions of lines of Java 8 and Java 5). Rust took nearly ten years to reach 1.0 from when it actually started (not just the few years from its 0.1 public release), and had to create a whole second layer of versioning (basically recreating C's approach as "editions") to help with issues caused by, for example, the fact that 1.0 in Rust didn't mean there would be no breaking changes (the 2015, 2018, 2021, and 2024 aren't on purpose), and how the continual split between stable and nightly had fractured the community based on the version of "Rust" that they saw day-to-day. Go prioritised backwards compatibility, which may have saved on upkeep, but it also meant that fundamental design issues and limitations are extremely hard to fix within the language (hence why it is not exactly uncommon for the classic code generation tools to be employed), as seen by how it took over a decade to add generics (whatever you feel about them), and that feature alone was years of development. C++ had a decade between its initial creation and "C++ 2.0", and then a further decade to get standardised and finally stop changing so much... and even that only brings you to C++98! JavaScript, once again, was around a decade until ES5, and nearly 20 years for ES6, and I'd wager most would consider those necessary compared to the original ES1/JS1.1 release.
That list can go on and on, since it turns out that programming languages are extremely difficult to make, let alone continue developing and improving; after all, consider the Python 2/3 transition, and how much fuss was made, how the updates were made, and now how there's comparatively trace amounts of Python 2 still being relied on because the calculus ensured that it was eventually better to update or replace, which is precisely what you would expect from a new major version, and which kept Python 2 officially going for 20 years, with over a decade for transition! I think that's reasonable enough period for most people, no? Do I need to go into dialects? The vast amount of even older languages still ticking over? The newer ones that actually started development in the 2010s (not 00s) and even more recently?
There are different tools for different jobs, and even if we are only considering the cases where people are picking those based on technical arguments (let alone logistical and personal ones) then the relationship with those tools will also change to suit the task. "It depends", as ever. Is it worthwhile to update to a new version? Well, what does it change, what will it cost, and how does that look both now and in the future? Are you making a big update every few years, or smaller updates more frequently? How it applies to Zig is the same as anything else, the only difference is that the "comparison" (which, again, is a bit of a fetch given the flavour feeling more like post-hoc "rationalisation" in the way an LLM is so prone to) for Zig is effectively placing it behind the starting line that others have already crossed (their supposed 1.0, LTS, or other version as adopted at scale), and it's treating a language (and its contributors) that is rather small and niche (again, as is to be expected pre-1.0, the same as was true for Rust pre-1.0 (however you want to account for the pre-0.1 era in that comparison), and realistically before 2018/2021 where its community had grown and really hit their stride... which is, once again, beyond that initial decade, around 15 years since it originally started), and which has repeatedly taken the public stance that they do not want people to use Zig if it's not the right tool for them, and that they need to understand how using Zig pre-1.0 must accompany an expected amount of churn (and, indeed, with no guarantee than pre-1.0 code will be backwards compatible with 1.0, which in some ways is a good thing because it means 1.0 provides a clean break that ensures code was written for Zig 1.0, and not the earlier developmental builds), with the trade-off being that 1.0 should provide a similar backwards compatibility guarantees as Go or C (indeed, taking so long to reach 1.0 lends credence that the shape Zig finally settles in is one that likely won't need to change all that much afterwards, so "never needing 2.0" might be feasible with Zig as well, and even if it does, a Zig 2.0 compiler will most likely be able to handle Zig 1.0 code even better than C compilers deal with version differences). Sure, there's a concern is that this messaging isn't clear enough, and maybe should be plastered on the site in bold, I understand that argument and don't disagree with it, but that's a very different thing from claiming Zig is a dead end of sorts (especially where, given the demonstrated longevity even amidst the churn, it feels to me that the correct reading of the title is "The Zig project is here to stay", even if that wasn't the "intention" of the piece).
Any programming language that continues to shift and develop will always be a perpetual experiment. That's what it means for every new version and build that changes the language itself, or the tooling it depends upon. The alternative is to pin an LTS version and stick with it; for Zig, that's 1.0, and it's not there yet, so hand wringing about it isn't exactly contributing to the discussion in any meaningful way. And even if Zig remained in perpetual pre-1.0 (which I doubt), where exactly is the harm? You'll either pick a version and stick with it, or you'll join the same Sisyphean cycle of updating that every other living language experiences, with the only difference being the tempo of releases... and it's not like you're required to update to the latest every night, so you manage the tempo you actually follow, making this simply yet another part of the project management inherent to all engineering (and one you can always test in advance, delay, and rollback on if required). Perhaps there's a consequence in terms of areas like community libraries, but Zig simply isn't used anyway near enough for that to be a significant problem compared to, say, Python, and it's more like how Rust crates could end up relying on nightly rather than a pinned/nominated "edition", yet still isn't because Zig hasn't reached 1.0 yet. To put it another way, Zig has had clear messaging, and there are plenty of mature, stable languages, so it simply doesn't get used in anywhere near the same scale, meaning it's only a small amount of churn, mostly by people who have accepted that as upkeep, precisely because that's a balance that most simply aren't ready for (certainly not in production) and so either decided to use something else or let it wait on the backburner until 1.0, maybe dipping in from time to time as a hobbyist. All of that is to be expected, and it explains much of the contributor and other early adopter mindset (because it is just that, early adoption, not a widespread tool you might expect to see in any team or project sampled at random). It just so happens to be one that found early adopters who understood the mission, were willing to get stuck in, and who believe it will end up a useful tool in the toolbox for more projects in the future (and is already a suitable one now), much the same way as Rust experienced (just with, usually, slightly less evangelising), and which clearly paid off (especially as, I suspect, many projects considering Zig, but that can't wait for 1.0 nor aren't able to deal with the churn, will likely settle on Rust as their best option, either for the meanwhile or one that will be more than good enough to maintain going forward... or will continue with C/C++ or whatever other languages they settle on).
As to the rest of the article? Well, it does seem like the biggest axe they have to grind is the AI policy the Zig contributors have adopted, and since there aren't any real arguments to it, it needs to be dressed up in some way as to rationalise the position and make it seem like Zig has made some objectively incorrect choice, rather than simply choosing to prioritise finding contributors and maintainers who would even put the effort in to "handle Zig at its worst", to borrow the turn of phrase, since it simply doesn't have (nor does it choose to pursue) the rate and scale of adoption that would make something akin to WG14 or similar standards bodies bringing stakeholders together (for better or worse, whatever the opinion, it's not consequential to this matter), and instead formed a coalition of the willing who would support and contribute the foundation (just at a smaller scale and buy-in than compared to something like Rust's). So, in that context, it makes total sense, since nurturing people is a key aspect for the language's longevity (especially considering how long many of the "inner circle" of contributors and standards committees tend to stick around in other languages, it can be seen as an excellent "return on investment", as it were), for which the explicit and noted trade-off is that, unfortunately, Zig is currently unable to foster those who feel they need AI tools to help them get started with Zig, but thereby freeing up the contributors and resources they do have to focus on the language and tooling (y'know, in actually getting it to 1.0), rather than dealing with the deluge; maybe the calculus changes in future, but I feel it's completely understandable that Zig, as a programming language (indeed, as programming infrastructure, as the article at least superficially recognises), has chosen to rely on people "putting the effort in", precisely because Zig itself needs to be trusted by all of its downstream early adopters (and, eventually, beyond), and it would need to maintain that for years and potentially decades to come if it is to become a reliable and trusted successor to C, which is going to require a contributor and maintainer community that can withstand that test of time (and implementation(s) to match). Sure, there's a trade-off, but just as Zig has to be trusted, so too would the AI technologies, and we certainly aren't quite there yet, so a small community with an even smaller "core" team choosing to unhitch from that bandwagon is probably the right call, since they simply do not have the scale nor backing to absorb the early adopter phase of AI technologies here in quite the same way others can. Hopefully, the calculus will change for the better in many ways, but there is no guarantee of that, so like any technical argument it must be weighed and balanced, and just as Zig isn't ready for widespread adoption, neither is Zig ready to change their policy (not that it has exactly changed much, despite the article's facetious claims to the contrary, or mistaken claims about Codeberg's reliability (part of the reason Zig jumped was because GitHub was unreliable, not the other way around) and so forth). Despite the gestures towards nuance, the article doesn't actually present much... but, given its tone and flavour, perhaps that wasn't intended, anyway; after all, it seems entirely serious when it poses "And apparently, contributors are expected to become deeply familiar with Zig's internals to earn the privilege of fixing something. Why?" without any of the basic critical thinking that "maybe infrastructure requires effort and understanding, as seen in other critical infrastructure's chartered engineers", for which "contributor's development process" is precisely the point because that's just what the practice of engineering and science is all about (i.e., ensuring the infrastructure you rely on doesn't just work by happenstance, and that people know exactly how to fix it when something does go wrong). But missing that is exactly the kind of lazy "rationalisation" that gives such an apparent "flavour", so I'm not holding my breath on it.
Whether or not I spent more effort writing all this than was made of the article, I certainly couldn't say, but the fact that it only took me a few checks on Wikipedia to confirm the dates and the rest was off the cuff, well, perhaps, just maybe, there's some value in people knowing some history? And maybe there's some value in some people knowing the inner workings of a programming language? Or is expecting something like that of the few people you are trusting part of your toolchain to suddenly a step too far? Whatever, I know this is commenting into the void, but it's cathartic.
Zig foundation is a non-profit with their mission being educating the "next generation of programmers". They decided against AI usage and I for one am grateful for a last corner on the internet that caters to the craft as opposed to literally every other community that has been reduced to discussing agent loops.
Again, ignoring the AI fingerprints of the article, all the criticism boils down to it being a project catering to different needs. You are free to fork it, name it Zag and run Claude on it to create the language of your dreams.
personally, I'm more alarmed that they're dropping LLVM in favor of their own backend.
good luck, boys.
Long-term, we do want to compete with LLVM for optimized builds too, but there are no plans whatsoever to drop LLVM support.
Just because AI bros can't put "Zig compiler" contributor on their linkedin page or CV doesn't make it an shit language.
> No LLMs for finding bugs.
Good luck with that in the era of LLM-discovered security vulnerabilities.
It's was in a presentation given at the tigerbeetle guys event.
There should be no slop code, no slop words, NO WAY TO TELL.
I couldn't give less of a shit if you use AI if nobody in the world could possibly tell. But that's not what any of this is about.
The latest uproar is because the Big Walk devs copy-pasted a some ChatGPT code into the game, and didn't disclose this on the Steam AI thing (I think it wasn't technically a requirement at the time because it wasn't AI generated art).
On Bluesky, a lot of people are talking about this as a sort of betrayal, and are saying there's no valid LLM usage, that even just using ChatGPT once in this tiny way is verboten.
I saw this exact same thing happen when Framework was cancelled for giving a laptop to DHH. I wrote about it https://blog.calebjay.com/posts/moral-contagion/ , and it's genuinely uncanny to see this replay turn for turn. There's some kind of underlying template going on here.
The properties are the same: a good guy (the Big Walk devs are known for, for example, refusing to publish on Xbox because microsoft is on BDS) dips a toe into a determined Bad, and in doing so, has become infected with an Original Sin or perhaps disease of association with Bad. Moral contagion. There's no difference between Framework giving a laptop to DHH and bringing him on stage and shaking his hand and handing him a million dollars - both actions are identically considered an endorsement of DHH's white supremacy. Similarly, using an LLM a little bit is not only the same as dropping ten thousand lines of slop code into a PR to curl, it's also the same thing as personally drying out a river feeding a poor village next to a new Datacenter, or, creating and posting a racial dogwhistle AI generated video, or chucking a double siege-heil on national telivision, because these things are all proximal to eachother, they touch, they're all contaminated. A leper ethical system.
Now Big Walk is cancelled. Which of course creates obvious incentives: god almighty, do NOT tell people you used a bit of ChatGPT, you'll never be forgiven. Or, fuck it, if you're going to do it, just lean in, because not only have you lost an entire demographic online, somehow just using AI automatically makes you more attractive to another demographic. For example, take a look at some of the Malfoid content on youtube, a lot of it intermixes American right wing iconography with their videos, since for whatever reason a lot of American right wingers identify with the trend.
Which to me means a lot of political identity is getting wrapped up in this. You can't talk to these people, you'll get hit with a "fuck right off" or "supporting fascism? Well that's certainly a Choice." Dogmatism reduces ability to critically think, but it doesn't matter, maintaining these boundaries is how a lot of people protect these online spaces they've created. They incidentally incorporate these companies they perceived as also within that space - Framework for its right to repair / green work, Big Walk for its BDS stuff and other left-aligned things they do - so there's not just a moral contagion aspect, but also a betrayal.
Which leads to my final thing I've noticed here, and others too: these erstwhile ideological allies are punished far more severely than objectively worse actors. Data centers suck up some water, sure, but the worse contributors to human caused climate change are oil and gas companies, who actively lobby to maintain their polluting industries over green alternatives (and even publish misinformation to do so). So why then is a person who drives a car instead of taking a bike or public transit not also tainted by moral contagion? What about people who buy clothing from sweatshop factories? Or the endless other evils under capitalism. Well because those companies aren't betraying us, they're just doing what evil capitalist companies are expected to! There's no betrayal.
So the end result is that good actors face far more scrutiny and can't make the smallest mistake, and all this online activist energy is burnt away attacking erstwhile allies and then purity-purging any of their own members who push back on this in the slightest. It's really frustrating to see this happening again with LLM usage, which "Lula's army" winning against Bolsanaro in Brazil (leveraging social media and AI-created content) conclusively proved that the left wing can use these tools to forward left-aligned goals.
If you start with a premise, then exaggerate to a dramatic degree, then your deductions don't actually follow from the premise, they only follow from the (unreal) exaggeration