> My point is that at some point one needs to recognize their project is used for production stuff and make stability the focus, rather than hiding behind the 0.x excuse for years. Call it the Peter Pan syndrome of open source.
We have a roadmap to 1.0.0 -- it's literally right there in the release notes -- and we're going to execute on that and then tag it. Ignoring that (and SemVer) and declaring that we should actually stabilize right now is a bit unreasonable.
> For comparison, Elixir started in 2012, and got its 1.0 in 2014, two years later. Zig stable has been ‘a few years’ for literally a decade.
This is a wild comparison to me, and I say this as someone who actually used Elixir for a time fairly early in its development (and still like it!). Zig has a vastly larger and more difficult problem space to deal with than Elixir.
> because my projects on github using zig uses LLM
To be clear, we do not block people for merely having LLM-related projects. Obviously we have opinions about LLMs in a broader context, but in terms of rules enforcement, we only care about LLM usage taking place within official Zig spaces.
It's possible you were blocked in error. LLM detection is not foolproof, so unless it's an open-and-shut case, our usual approach is to just unblock if people reach out to us by email.
I would understand if its by error but based on how it was banned it did feel deliberate. Also I have written email to core member before making a decision to leave the community. I think a community can only thrive when they are nice to humans. Here it felt like zig is worse then a oligopoly where few core members can block anyone without any reason and don't even have a courtesy to send a message. I worked with python community since its beginning, same worked with linux community since 1992, never seen such attitude even though both of the projects were driven by benevolent dictators, but they did care about the community around it. I still have one major work [1] in zig, which I will still release but after this won't work on zig. Zig community felt like a hostile ologipoly of few core members without proper due process, when it comes to treating humans.
Well of course the block itself was deliberate. By "in error" I meant that we might have misjudged the text as being LLM.
Who did you email, when, and did you get a response? We've all been very busy leading up to the release, and most of the team is also currently traveling for SYCL.
Regarding sending a message, consider our side: We're tired of having our time wasted on slop, so we don't also want to have to write formal block notifications to people we block on suspicion of using LLMs. I'm fully aware that this can lead to an unfortunate situation like this, however. For what it's worth, this is why we want to move to an invite tree for Zig development; it'll allow us to create a high-trust environment where this kind of suspicion is unnecessary.
Thanks for the reply alex. I send an email to andrew, but not to reinstate my account just to send the details of the incident before I move on.
I wish all the success to zig because diversity keeps the innovation alive.
The reason I moved on is, after 2 times consecutively facing the same issue, I felt I will be helpless in zig community and felt like my voice will be muzzled without any reason done in an opaque and abrupt manner. I prefer to err on the side of openness than caution.
Initially I posted my project on ziggit forum. Respecting the rules, in my post I did mention use of LLM extensively on those projects. One of the post asked "If I used LLM", I did not get a chance to replay, right away my account was blocked on ziggit for 1 year. Thats ok I accepted it, I thought I should respect the community.
In the second incident I opened a small PR with an issue which I fixed for my own project, later I created a PR. I did understand that zig community do not accept LLM written post or PR on their official repository, so I went ahead and wrote the issue myself, also for PR I wrote the code, run the test locally on my own PC, tested if it compiles and pass the test on my osx and linux. Since it was my first PR, did not expect it to be accepted and thought may be some core developer will pick the code and merge or write another code.
Also I created one more issue which was closed by the core developer with a message its fixed in 0.17, I thanked the person.
I saw one issue from another person facing similar issue as mine. I give a comment and also put a code snippet for him to try on his own machine, since on my machine it compiled correctly and created windows cross compiled library on my linux machine. But then suddenly I cannot see my issues, my comments and PR. I initially thought issue with my own system it was not so. Then thought may be codeberg blocked it, but that was not the issue either. Then I spend significant amount of time going through forgejo documentation to find out that a person running a project can remove the person from a repo and their whole history and work will be gone from that repo. I have other repo on codeberg which worked fine with my account, so then tried to create new issue in zig repo to test if I am being blocked.
This is when I realized then my account has been banned by some zig core developer deliberately without a single message, including no message that my account has been blocked. This is like a tyranny of minority and community do not build like this.
A community requires a due and a transparent process even if its benevolent dictatorship. Since it happened twice in a span of just 2 weeks, it really felt like zig is not an open community and breeds strong disdain towards people working in AI or LLM. I then realized that I made too early decision on bun incident, where I took the side of the zig core team, now could understand the other side of the coin.
I have been following zig since it was started, just didn't take the plunge, but once I took the plunge and met hostile community, personally I thought I should move on. Still I believe in diversity of opinion so will still be happy to see zig thrive as a language because I liked its simplicity and also diversity breeds innovation.
If there's an edict that no one is allowed to bring up the topic, how can someone change this part of the code of conduct?
Asking non-rhetorically. It seems like one position "ai in any circumstance = bad" is being enforced. The commenter above didn't even understand why he was ignored.
Interesting to hear! We maintain the project Antfly (entirely zig) and have been nervous about bringing issues to the zig folks or asking questions because of our ai usage.
We’re quite knowledgeable and thoughtful folks fwiw
I think I’ve seen you are a core team member or contributor? I remember your tag?
So for instance because of the size of our codebase our project has pushed Zig to some of the edges, specifically we end up hitting a bug when using llvm and zig on arm64 (Mac and Linux) where it seems to be caused by some configuration Zig passes through to LLVM. I’ve used codex and claude to help me diagnose and find the bug (we use nix’s glibc zig to circumvent the problem now). I now understand the root cause but am not sure what the proper fix would be. But I’ve not known whether or not even raising the issue would break the terms of contributing? Would raising the issue break the implicit agreement?
I would suggest just starting by filling out the bug report template, i.e. steps to reproduce, expected behavior, and observed behavior. If for some reason you can't provide a reasonable reproduction, the symptoms on their own can sometimes be enough for us to make an educated guess at what's going wrong.
Regarding whether you should post the root cause analysis: Per the current policy, the answer would have to be no.
I do personally have more nuanced thoughts on this, and I started typing them out... but then I realized that my reply was getting dangerously close to blog post length, so I decided to restrain myself and commit to turning it into an actual blog post later. In a nutshell, though, the problem is that even if there is such a thing as responsible use of LLMs for bug analysis, the only way we can currently be confident that someone possesses the required qualities for that is by working with them for a while.
I understand, maybe one day I'll have the chance to hear the blog posts' worth of thought on the matter!
https://codeberg.org/ziglang/zig/issues/37060 I opened the issue and can give you the agent generated RCA on the matter if you all want it in issue 604 on antfly's github but I understand that's against policy and totally respect that.
Appreciate all the work you guys do and have been following the whole Zig project since inception fwiw!
The fix could not be backported to LLVM 22 because it changed the LLVM library ABI. We also could not skip straight to LLVM 23 because that would make life harder for distro package maintainers.
Was loop vectorization by chance enabled in 0.15.2 and disabled since 0.16.0? One of my projects got 14% slower after upgrading to 0.16. I didn't dig in yet but I assumed the Io vtable was the cause (it does a lot of file io). But if the versions line up maybe it's actually loop vectorization.
It would be a bizarre approach in Scandinavia because the consensus here is that companies must pay their employees a decent baseline salary -- which unions negotiate across the whole sector -- so there's no expectation of a tip by default.
But for much of the rest of the world, it's not a given that working conditions are as good.
The Zig issue tracker is for technical discussion; you are more than welcome to engage and debate the idea on its merits. But we do indeed delete meta-commentary, wild speculation, and outright hostility.
Apparently I'm not. Directly from andrewk himself:
If you want to comment in this thread, please either have your open source zig project(s) visible on your codeberg profile, or be Fil Pizło, otherwise zig issue tracker is not interested in what you have to say
This itself is hostility towards anyone who isn't a zig expert pretty much.
This is the Zig repository. It is totally appropriate to expect people to be Zig experts when working on Zig itself. People should understand the repository they are talking about. If you're not even invested enough to write a project in Zig, of course your opinion is nothing but noise.
You don't need to be a Zig expert, but you do need to at least be invested in the Zig ecosystem in some way.
I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place.
If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on the future direction of the project and debating a proposed feature, I would absolutely expect people to be annoyed about the noise I'm generating.
The difference is that Rust doesn't gate comments on proof-of-use, even if core contributors might find it annoying. Honestly, this is the first I've heard of such a policy in a project (though no doubt it exists elsewhere, in the infinite span of F/OSS projects).
This isn't to say Zig's stance is unreasonable, it may even be sensible. But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case. Some people may be welcome to do that; even if there is a strong technical argument or important questions being posed, you are explicitly not welcome unless you meet that criteria, as evidenced by real comments being deleted from that issue.
> But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case.
I really didn't think that part had to be stated explicitly; I genuinely don't know why someone not invested in Zig would even feel the need to go debate on the Zig issue tracker. But even setting that aside, this is far from the first time that the core team has made it clear that we don't want the internet peanut gallery to brigade the issue tracker.
> as evidenced by real comments being deleted from that issue.
This is about a strictly-enforced form of run-time memory safety where there's no `unsafe` escape hatch that a careless programmer can misuse to undermine the memory safety mechanism. Contrasting with Rust is helpful to get that point across - which the body text of the issue does.
I can't speak for Andrew, but I didn't read this as a "diss" at all.
Sure, the point makes sense but if that's the sole point I think communication is quite bad. Fil-C is memory-safe only if the whole stack is compiled with Fil-C: this does not hold for Rust which does not require to recompile every dependency. Some dependencies cannot even be recompiled.
So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
> So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.
Safe Rust still basically always links against unsafe C libraries though. Fil-C will only link against libraries compiled with Fil-C which makes for a vastly stronger guarantee.
Also, plenty of code written in Rust is not safe so "if everything was built in safe rust, then it would be as safe" does not hold. There's definitely no way to write safe inline assembly in Rust.
It would be more accurate to say Rust doesn't have the option of recompiling every dependency. If a safe Rust program links to an unsafe C module, that program is not memory safe. The "unsafe" on FFI code is not a joke.
> I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use
I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this.
> and their flagship project has now abandoned it.
Quoting Andrew:
> So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.
I advise you to take this paragraph at face value. Again, I promise you that it is the truth.
> Both Windows and macOS do so much better out of the box for essentially any workload.
We test FreeBSD, Linux, macOS, NetBSD, OpenBSD, and Windows in Zig's CI fleet. Of these, Windows is the only OS that we've had to configure with swap double the size of physical RAM to not hit completely unjustifiable OOMs.
By "unjustifiable", I mean that we're not even close to actually running out of physical memory (let alone swap), but the MM seems to be doing a horrible job of making unused memory actually available to processes.
It's possible there's a relevant configuration knob here that we're just not aware of... but the point is, the default behavior does in fact suck.
Windows will autogrow the page file (*swap file is separate from a page file in Windows; swap is exclusively for UWP apps) as needed.
It sounds like the application wanted to allocate contiguous regions of memory when none were available. That's a typical indicator of an 'early' OOM condition.
Windows seems to work a lot better with a 16MB page file for whatever reason, just because it refuses to enable memory compression without it. Fucking stupid
Am I missing some sort of common-sense explanation of why page files are so great? I have enough system memory that I shouldn't need to spill it to disk.
No, that's not the common sense you are missing ;-)
Your system your rules. But you twiddled a knob to appease your tweak imp, you didn't like the new behaviour, so you called it "fucking stupid". My experience is that the windows vmm is a very high quality component, so simple heuristics tells me PEBCAK.
I can think of two different possible reasons why memory compression might require a page file. Until you understand the technical reasoning, you don't know whether the design is stupid or clever. So taking a strong position is _eliding over a core tenet of wisdom_
> But you twiddled a knob to appease your tweak imp
I ran out of disk space because Windows decided my page file should suddenly be 64gb. With no space left to save my work, I found out there's no way to shrink the page file without rebooting. Of course the next thing I did was try to cast it off.
Maybe it was my skill issue for not expecting a sudden 64gb file there... or my skill issue for not choosing a nonzero size after?
That's a good reason, I might do the same. I certainly used to twiddle that setting trying to make space for Sim City 2000 on an 80MB disk.
I see a major footgun in memory compression that Linux doesn't care about - it'll just oomkill your shit, hence TFA. But footguns are not acceptable in mass-market software. Apple also removes them.
I don't understand how swap helps when you already have enough memory though. The article seems to say it's important to be able to swap out anonymous pages, but why? Especially when you aren't under memory contention? Just because memory isn't needed yet doesn't mean it's a benefit to get rid of it. It takes time to swap it to disk and then time to get it back. Why is that so important? Why would the kernel turn off things like compression otherwise? Makes no sense to me. No swap = punish the user by being less efficient on purpose? That's no argument for swap at all.
reply