A rather balanced take, I admit, though fairly critical of Zig.

It's AI slop, as others have pointed out

zig project not going to AI, so "author" (claude) says its going nowhere

The article itself is certainly going nowhere, slow.

A language without a framework or software product that makes it unavoidable, hardly takes off beyond early adoption curve bump.

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.

Libghostty 1.0 - https://news.ycombinator.com/item?id=50399933

Maybe not unavoidable product, but zig has a vision, do not need to go different direction or make product immediately or die

It's flagged by major antivirus vendors, like Sentinel One.

I build based on libghostty, but with Typescript and Golang. I read this article precisely because I was worried about the future of Zig, despite not programming in it directly.

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.

The UNIX world is full of terminals, though.

Python is an extremely popular (and successful) language that is profoundly uninteresting.

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.

Python got successful thanks to Zope, and being a better Perl in the late 90's.

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.

Thats only because the chicken and egg problem prevents it. We are in a new world where this problem is solvable. Fake it until you make it. Use the LLM to give you what you want first and humans can backfill what is important later.

The language isn’t yet at 1.0. You don’t need a concrete commitment to stability in an inherently unstable development phase.

The important question is when/whether it will hit 1.0 and what its commitment to stability looks like _afterwards_.

The article addresses that pretty directly:

> 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.

You can use zig just fine these days Ghostty, Tigerbeetle and bun before rust rewrite proved it. So i could care less if 1.0 lands next year or in 2033.

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.

There is likely some project out there that successfully used Brainfuck.

Doesn't mean much.

It's been in development since February 2016 and currently sits at version 0.17…

Would version 0.985117 be better?

You may have a point if zig have the budget of big cooptations or sponsors. It wasn't even full time until 2018 and went through COVID + other things.

Why is this slop article on the frontpage ?

This

Meh, Zig doesn't owe anyone anything. If you want a blub language that won't break compatibility, use Golang. If you want a fully mature low-level language, use C.

Not really active in the Zig space but it doesn't really give me a good impression how Kelley appears to use Zig as his personal megaphone. For instance the GitHub migration post, which I don't disagree with, but was written like an emotionally charged personal blog post.

re stability/backward-compatibility: that's not inherently a bad thing if it leads to better abstractions, also easier w/ ai assistance now to adapt when there are changes

(python 2 to python 3 migration would have been less of an issue now as well)

claude seems to have missed that LLMs make light work of updating a zig codebase across the breakages.

personally, I'm more alarmed that they're dropping LLVM in favor of their own backend.

good luck, boys.

To clarify, we are not dropping LLVM; we are just also developing our own backends with full support for incremental compilation.

Long-term, we do want to compete with LLVM for optimized builds too, but there are no plans whatsoever to drop LLVM support.

> 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. And that is a serious problem for a programming language.

Not true! It just means (realizing a) vision is more important to them than becoming popular. It's their choice to make.

same thoughts

> It's their choice to make.

It's also a choice many of us wish in hindsight our tool makers had made.

That's just a restatement of what you quoted

[delayed]

I don't think you end up with a project like Zig by wanting to compromise and ship quick to watch adoption grow. That doesn't make it any more stable at the moment, or necessarily any time soon, but it does mean you actually get a language like Zig.

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.

The writing has been on the wall since Bun migrated.

The stability comment makes some sense but the rest of this article is just complaining for the sake of complaining. Clearly their "no AI contributions" policy is not preventing the language and ecosystem from improving. And nobody says you can't use AI to make Zig programs.

If you use an LLM and completely own the output, NOBODY SHOULD EVEN BE ABLE TO TELL.

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.

Programming languages don’t need to go anywhere, add more features or adopt political causes.

It’s fine for them to just be.

From Zig's Code of Conduct [1]:

> No LLMs for finding bugs.

Good luck with that in the era of using LLMs to find security vulnerabilities.

[1] https://ziglang.org/code-of-conduct/

Andrew already opened up about using LLMs for finding bugs but it will be done after they covered all other bug finding methods. This opening up came from what the sqlite guys presented about using LLMs for finding bugs and the zig compiler team hinted at following the same bug squashing route that the sqlite guys followed.

It's was in a presentation given at the tigerbeetle guys event.

oh my god

Time will tell, but using Bun moving to Rust as evidence that Zig is doing it wrong is hilariously backward. Bun YOLOs a vibe code Rust port as it is absorbed by an AI company and you think it was the language ecosystem at issue?

> The language continues to break compatibility without a concrete commitment to stability.

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 split usually isn't 0.x (not ready) and 1.x (stable). Instead it's 1.x (established enough) while working on 2.x, then 3.x, then ...

The way I read it, the post seems to argue they have enough users already to seriously consider cutting the first stable release.

Had a good chuckle reading this.

I maintain many large Zig projects (see profile) and none of this matters to me at all. Why should I care what the core team thinks about AI, which code forge they use, or what internet drama happened between them and Bun? I'm too busy building things to care about this HN gossip. It doesn't affect my use of Zig as a tool.

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.

For everyone to be aware this site's about page states:

""" 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".

I love AI adding stuff like "in my experience" in a vain attempt to mask the fact it's bot written, as if this is what is missing

Well, in case you want to read the actual article about CheerpJ 5.0 [written with my own hands :-)], you can go at the source.

https://labs.leaningtech.com/blog/cheerpj-5.0

Learning Technologies makes some interesting WASM powered software, I'm glad to see people are making a living working on this.

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.

I fell for it. Appreciate you pointing this out.

Literally the first sentence of the article "Zig keeps improving as a programming language.".

Just because AI bros can't put "Zig compiler" contributor on their linkedin page or CV doesn't make it an shit language.

> Merit alone is no longer enough.

Master Foo, who gains more merit? He who writes ten thousand lines?

Or he who, recognizing the emptiness of the endeavour, writes zero?

Typically I’d say “fork it”, but here, I would actually recommend designing your own language for its niche (a modern C, a performant language without Rust’s annoying memory management), having an LLM implement it, then open-sourcing with examples and measurements (how easy is it to work with? How many bugs are in generated code? etc.). These languages are bound to be so similar that, if one proves better than others, LLMs can port the others’ code. And it’s very fun, and you get a language with features specific to your use-case, and bike-shedding in your favor.

Waste of time, when the replicator device can spew anything, target machine code directly.

Honestly, making any argument off Bun's switch to Rust is the point where I can't take anything in the article for serious anymore. I don't see how that particular case can serve as solid grounds of argument for anything yet at this point, and it just nulls out credibility for anything in the remaining article for me.

Having a powerful language going fully anti AI is awesome because you will have something to compare against in the future. If we conclude that it was a bad decision, it shall die. If it wasn't, we will learn a lot.

Haven't considered this take and makes me wonder how we might be slowly losing baselines to compare against (other than targeting years old releases as a sledgehammer guarantee).

That's the problem with personal ownership as far as programming languages are concerned - beneficial dictators for life, even if well-intentioned, can still meet their own criteria before anyone else's.

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"....

Like with democracy the one with the deepest pockets will have the most voting power.

This article doesn't seem to have be written by any actual person, let alone a person who has worked with Zig at any point in time.

Fayten makes a good point here https://news.ycombinator.com/item?id=50452445 About this article is 100% clickbait and 0 substance

The response to Bun switching to Rust use what cemented my decision never to use Zig again.

I bought the book, I started projects, but I was wary of committing for the reasons stated in the article: the instability of the language, the capricious decision making of its leadership, and the evident concern for in-group purity over project well-being.

It's more a toy of a small community of like-minded developers than a product for general consumption.

So 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.

Did you use AI to write this comment? It has all the tells.

This looks like a pointless polemic more than any valid critique - I would be interested in taking a look at the prompts that produced this angry slop article.

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.

> Not everyone wants to become a compiler engineer. Some people encounter a bug while trying to build their own software and would simply like to fix it. That's a perfectly legitimate contribution whether you intend to work on Zig for the next ten years or never touch it again.

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.

If you use LLM to accelerate your learning then wouldn't you be able to explain your PR with the compiler team? Given you should have learned and understand what you made.

I think you can debate Zig's choices, but this reads like AI slop on a AI slop website focused on Zig's exclusion of AI slop contributions.

> 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.

I don't like to use big, sharp and divisive words but for lack of better ways to express what I think, I'm gonna say it straight up - it is extremely stupid.

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

I'm seeing an anti-LLM dogmatism across Mastodon, Bluesky, and Github discussions, among people I guess identify as online activists, or maybe just, activists who happen to be online.

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.

you seem to be leaning really heavily into hyperbole, and then making logical deductions from the hyperbole.

If you start with a premise, then exaggerate to a dramatic degree, then your deductions don't actually follow from the premise

Nice try Jared. Sorted out the Rust Bun issues yet

Even worse for zig is that programming languages don’t matter anymore.

What an embarrassing way to miss how the fundamental promise of Zig's pre-1.0 mission being "things will change so that we get 1.0 right the first time around", so breaking changes are expected because that's the bargain! If you want to help Zig reach 1.0 and be the right kind of language for your needs from then on, then taking part in the ongoing and open development process is the cost of entry. If you can't wait for 1.0, then don't use Zig because it's not ready for you. If Zig in its current shape isn't the right language, and it doesn't seem like it would at 1.0 be based on the prior trajectory and current work, then there's probably another language that's a better fit (this is, of course, why new languages keep being created). But, if Zig does seem like the right language, or at least is close enough, then the balance of upkeep is part of the calculus in choosing to use it, like with any technology, and at least Zig is honest about that upkeep being higher now, with the purpose of 1.0 being the point what that would drop to something more akin to the older languages with several years, if not decades, between major version changes (at which point providing the tooling to help assist upgrading and dealing with breaking changes, in turn, also becomes worthwhile to invest in, making long-term upkeep even easier). For Zig, that's what 1.0 means, just as with something like Go 1.0, or standardised C, it's a version of the language you can stick with for as long as you want, without dealing with any breaking changes.

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).

> A programming language cannot remain a perpetual experiment without consequences.

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.

I ported a WebGL fluid sim to Zig and raylib and shipped it as a native iOS and Android app with no engine.

I am of the opinion, that the responsibility of maintenance and keeping things compatible, falls completely on the developer using it, when it's not version 1.0 yet. Yes, it has been in development for a long time, and it's reasonable to fear that it might not reach 1.0 for too long. At the same time, I find that many projects are afraid of breaking compatibility, which usually ends up with this half-baked solution, with things plastered on top.

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...