Re:The Zig project is going nowhere
by babel_ on Wednesday November 11, 2026 @09:21AM
(#50453770)
> 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.
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.