Yep, it's true, but the reality of what it would take to actually fork and commence with healthy use of AI alongside with the elusive soft/hard stance needed to lead technically and socially is probably a bigger challenge than anyone is willing to take on! Soo.. slow and (rather?) well it goes for Zig.
They seem to be doing fine. Tigerbeetle and Ghostty are two projects that continue to do well and are written in Zig. The foundation’s funding also seems to be doing well. They are continuing to make releases.
Strange in what way? Mitchell has also stated that he reviews every line of code that goes into Ghostty so I don't think its quite the same as the Bun rewrite.
He can say that … but after reviewing the 1000th PR from a LLM and only finding minor issues that really go down to subjective taste, I think he may start to reconsider that.
Really, even after a LLM has gone through a review and fixed issues found? I almost never see anything relevant since around Opus 5 came out, and now with Fable and Opus 5.5 whatever I think is wrong is almost certainly right.
On my small personal projects I seldom find any mistakes. I use Chinese models on those. GLM, DeepSeek, MiMo.
At work I use Claude, but it is a considerably larger and quite complex codebase. I use LLMs a lot, but it is a common weekly occurrence for me to correct misconceptions, bugs, or overengineering from Opus/Sonnet (Opus plans and reviews, Sonnet implements).
I just noticed it today upgrading to 0.17.0 from 0.15.2, while doing bitwise operations a lot of large integers. I haven't looked at a debugger yet, but my guess is that would benefit a lot from loop vectorization.
It may surprise some people here to see that Andrew is warming up to using LLMs to discover bugs (inspired by results from SQLlite) and considers it a tool on the path to getting to bug free software.
> It may surprise some people here to see that Andrew is warming up to using LLMs to discover bugs (inspired by results from SQLlite) and considers it a tool on the path to getting to bug free software.
Someone in the thread below says their bug was closed because of mentioning that they use AI to confirm the bug they had encountered. Is he going to go back and reopen all of those now that he learned what pretty much everyone else already knew?
> Someone in the thread below says their bug was closed because of mentioning that they use AI to confirm the bug they had encountered
I don't know about this particular case, but if I saw someone report a bug and as evidence claim they had X Y and Z LLMs verify it I would be pretty upset. If you're going to use an LLM to make a replication, just do that and give me the replication, don't point to your notoriously error-prone tools as though they lend your report credence.
It's in a similar vein to people who reply to questions with "well Claude says: <chat transcript dump>"
I feel very torn as a maintainer on this, since the only way to respond to the increased noise from AI has been to have AI do the research for me to extract all the links and line numbers I used to have to find by hand to explain why the PR needs more effort to be completed. But I also will be highly dismissive of any submitter who just posts AI text without cleaning it up first. It feels hypocritical, but the alternative is that I just can’t respond to most people instead due to limited bandwidth. I mark if something comes directly from the LLM though and to try to express my degree of confidence in its claims.
Seems like we might need to go to different issue tracking model for AI reports. Such reports must not only provide a bug report/issue but must provide a fix as well. That fix must then be reasoned back to why it solves the bug, why it is minimal, why it is unlikely to silently cause new bugs. It can't introduce new capabilities/side-effects. The platform verifies the claims in the report using another LLM. Then the tests are run, which are no longer publicly accessible to avoid slipping malicious code through the cracks. When okay the patch can go into staging. Perhaps a special version containing only accumulated AI fixes.
Human reproductions are notoriously error prone whether ai assisted or not right? I’m not sure what the analogy is between “llms are error prone” and “thoughtlessly copy-pasting something from Claude” is.
Human reproductions don't have to be bad. It feels just as justified to push back on a bad bug report whether human or AI and say "I don't have enough to go on here".
If a report is improved and becomes actionable, that's great.
Why? Shouldn't everybody already know that using AI to find bugs for oneself is amazingly efficient, but using AI to submit bug reports for others is quite the opposite. Burden of verification and all.
Exactly, the main issue isn't the LLM creating or confirming the report. Rather, the maintainer has no idea how it was prompted, and the results may be completely wrong. Some LLMs also have a bad habit of trying to please the user, confirming their biases.
I don't care how it was prompted any more than I care about what exact thoughts went through your head before you realized it was a bug. The problem isn't usually a lack of information, but the abundance of non-information. Chatbots and the people who use them to pen bug reports frequently seem to have had "no time to make it shorter", as Blaise Pascal put it.
That you used an LLM to "confirm" the bug is an example of such non-information. The reproduction testcase and/or the reproduction steps and description of the expected outcome confirm the bug.
But if I called you in the middle of the night to offer you something that will make every 9th sneeze on every second tuesday of March in a leap year less irritating your first reaction wouldn't be to thank me.
If I were making a product to try to eliminate sneezes, and someone said "I noticed an issue with it, and after I looked into your manufacturing process, I think I figured out what's causing it, so I double checked using an AI tool and it added further evidence that the defect I found is legitimate and would be solved by the solution I had come up with", it would be bizarre for me to say "I would have accepted this if you didn't spend the extra time at the end to verify your existing findings with an AI"
He specifically says in that presentation that they are open to LLMs helping them get to bug free, but because the language is still in flux, they would rather prioritise bugs users actually find rather than those found by LLMs, essentially with the intent of unblocking people rather than wasting time fixing things that may need to be fixed again or be wasted work come the next update.
My understanding of the situation is that the user did find a bug themselves, because it literally broke on their own code, and then they just had the LLM help them verify their theory of the bug that they already had.
Neither of those are my understanding of what happened: a human found a bug, and then had an LLM verify their theory of the issue. To me, that's just extra due diligence and pretty weird to use as grounds to ignore.
They want to focus first on bugs hitting people's actual code to unblock them, not theoretical bugs that LLMs can hit by coming up with some contrived code, regardless of the quality of the bug report.
Andrew is a real weird guy. On one hand, he's innovative enough to see possibilities which made him create Zig, but at the same time it boggles the mind that an such an intelligent person can be so utterly stupid when it comes to LLMs. Makes me wonder what other stupid decisions he makes, tbh.
I personally think using AI is of no problem for certain cases. It is absolutely pissing off when someone tries to generate slops that too verbose to review only to increase the complexity of the codebase meaninglessly.
Back in a more adult age, the way that this was handled was "We've benefited from our past collaboration, but we believe a new direction is needed going forward."
For some reason--COVID brain rot, poorly-socialized people coming online, general increase in viciousness in the population, who knows!--people have forgotten the utility and purpose of boring polite manners and communication.
Andrew wake up! The machines is already among us. It's either you will use them, or they will use you.
---
Take this pill (////) with plenty of water \_/
Nope, but why would it matter? Nobody is stopping you from writing Zig code with an LLM, the policy you are referring to is only relevant to the compiler source code - which must be ABSOLUTELY human reviewed - for security reasons, maintainability reasons, etc.
Not the parent, but some people may feel like it's betting on a bad horse. Zig already has a small ecosystem, so pushing culture that may make it even smaller while having core development stagnate in an ever-accelerating software world may be seen as a tougher sell.
I’ve written software for a living in JS, C, Pascal, and Go, and I’ve tried many, many more languages. After working on a project in Zig for a year, I’m convinced that Zig is the best-designed language I’ve tried so far. Haskell comes close. At least, it’s the best-designed language for humans.
It’s not for everyone yet. It’s still unstable, and its ecosystem is small. However, both are improving.
I'd like to learn more about the connection between Zig and Haskell as they seem almost opposite in design and philosophy. I'm pretty sure you just meant they're both "good languages" but if there are parallels I'm missing I'd love to know!
I'm not the person you asked, but I see them both as languages that try to get a lot of mileage out of a few features. Both of them try to have small cores, instead of taking a "maximalist" approach like C++.
> It’s not for everyone yet. It’s still unstable, and its ecosystem is small. However, both are improving.
To be fair, I've heard this for years now, yet the hype keeps mounting. I wasted half an hour this morning debugging a broken Zig project, all because I used a release a few months too new that removed some options used in build.zig
Releasing stable software and caring about backward compatibility is a skill many open-source maintainers don't ever want to engage with. It's so easy saying "our code is not stable, if it breaks good luck to you", but at some point it starts to smell like fear of commitment to running a serious project that people depend on.
Why such high expectations from a 0.x project? They explicitly break backwards compatibility now so they don't have to do it once 1.0 comes. There's nothing wrong with waiting a few years before trying Zig.
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.
> 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.
Congratulations to zig team. Good to know they are trying pragmatic approach to LLM now. I left the zig eco-system due to zig core members hostile behaviour toward humans not just LLM, so good to see the change they are becoming pragmatic. For me I am slowly porting the same work to odin language [1].
Background is I created issue and one pull request to fix them in zig compiler version 0.16.1 issue numbers 36812, 36811 (you cannot access them as my account is banned). Respecting the community’s no AI stand. For these specific issues I wrote the issue and code myself and not let AI write it. Spend a lot of time on it. Subsequently without any notice my account was banned because my projects on github using zig uses LLM. This was done without message or any information. My account was banned on zig repository.
I can now understand the other side of coin how bun team might have been treated with disdain when they used LLM.
I wrote an email and left the zig community, have many work in zig but slowly moving them to odin.
I feel personal disdain should not be spilled on to people who are pragmatic on using LLM. I was a very big evangelist of zig for their no LLM stand and promoted them among my community, but with poor treatment by community I just left. You can still see projects I wrote in zig [2].
I have worked with postgreql community since 1997 and python community since 1998. Never felt such hostile community. So all the best and I wish zig continue its progress
I don't think the zig community is necessarily hostile to LLMs, they just don't want it in their "maintained by 10-ish core people not even full time" language impl. Mitchell Hashimoto, a big zig contributor (both money and effort), for example, uses LLMs a lot and no particular shade is thrown.
This is from my own first hand experience both on ziggit forums as well as raising bugs in zig repository. My account on codeberg is still banned on zig repository without any single comment, my issues or pull request raised on that project just went in ether without being accessible, if you see the issue yourself could have made the decision if it was warranted to ban the account, but that right also taken by the core contributor out of spite and disdain for LLM.
I have been in open source world with linux kernel since 1992, never every had seen a community so hostile, especially towards humans who spend time and efforts just out of curiosity, inquisitiveness and trying to support some simple alternative when odds are already against them.
Facing hostile behavior from inside the community made me switch to odin language where they also do not use LLM but are pragmatic about people using it. Cannot comment on Mitchell because I do not contribute with money.
I mean I pr'd something (and it was not accepted) but the grounds have nothing to do with LLMs. I'm pretty vocal about using LLMs to write zig code. Obviously I did not use LLMs in my PR
I would be fine if they reject the PR, given I was first time raising it to fix POSIX related issue. It was just few lines of code. But my account was banned all issues removed my own PR not visible and looked like tyrannical approach not a benevolent dictator approach. I think being nice to another human being is the basis for building community. Here felt like if you are among the few who dictate the terms there is no process just my way or highway.
It is not codeberg, I can work on other repository properly on it. Its only zig repository where my account is blocked. My initial thought was same as you, only later realized it. Also on ziggit these people did the same even though based on policy when I put the post i clearly mentioned use of LLM. This all without any proper communication. After working on zig for over 6 months, now I am moving slowly to odin [1] language. This decision I did not take lightly, I had spend significant resources in zig earlier and now moving away.
> my account was banned because my projects on github using zig uses LLM.
Its not Zig. Its codeberg. Codeberg has a strict no-AI policy. Codeberg is ALL about the community and not the lone hacker. I think its a good policy to prevent overload and clearly distinguish project ecosystems from each other.
> 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.
don't let people gaslight you here. i mean, look at how the creator treated a person who was a zig evangelist and was donating tens of thousands of dollars to the project:
"Jarred was already writing slop well before he had access to LLMs."
"Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show"
"When Jarred announced the Rust rewrite, we were ecstatic. It seemed too good to be true. I have to admit, I didn't think the technology was there, to pull off this stunt. But he did it, and now I'm metaphorically sipping delicious tea from a mug that says "It Tastes Like It's Not My Problem Anymore"." [1]
or what about when he called people "monkeys" because he didn't like their product [2]
or when their vp of "community" called github employees clowns [3]
so don't let people tell you that there isn't a pattern here. and when this kind of behaviour comes from the top it shapes the rest of the community
This is getting really close to 1.0 now? I guess may be 2 more release and 1 more RC? That is 2028. I am looking forward to stabilising the language and the core team has previously indicated that exporting ir will be a supported feature.
Once that is done, @dnautics is working on memory safety for zig [1]. A Checker for Lifetimes and other Refinement types.
Then we can start the Rust vs Zig Debate again. Hopefully not too late.
Given the efforts we are already seeing where people post "I rewrote X in Rust in 24 hours using the latest agental harness", I don't think there is any kind of "too late".
Either Zig gets good enough to be a worthy re-write target, or it doesn't. But I suspect that isn't even what they want.
I imagine languages are going to bifurcate into ones that go all in on agent experience and ones that go all in on human experience. And Zig seems to be in the latter group. I am confident that there will always be some niche market for languages lovingly crafted for humans. But the criteria we will use to define success within these groups of languages will be different.
I’m actually going to be a little bit sad when Zig does hit 1.0 and slows down with the rewrites of core functionality. It’s not for everyone, if you have SLAs on production I can see you getting sick of it quickly, but no programming has ever felt as alive for me as right now in Zig. It’s like the various JavaScript heydays of Bluebird, Node, Babel, ES6 etc all rolled into one.
104 comments
[ 3.3 ms ] story [ 46.4 ms ] threadAt work I use Claude, but it is a considerably larger and quite complex codebase. I use LLMs a lot, but it is a common weekly occurrence for me to correct misconceptions, bugs, or overengineering from Opus/Sonnet (Opus plans and reviews, Sonnet implements).
https://youtu.be/zwi5b5xSsKA?is=PTjJJjSnVMdRuZag
It may surprise some people here to see that Andrew is warming up to using LLMs to discover bugs (inspired by results from SQLlite) and considers it a tool on the path to getting to bug free software.
Someone in the thread below says their bug was closed because of mentioning that they use AI to confirm the bug they had encountered. Is he going to go back and reopen all of those now that he learned what pretty much everyone else already knew?
I don't know about this particular case, but if I saw someone report a bug and as evidence claim they had X Y and Z LLMs verify it I would be pretty upset. If you're going to use an LLM to make a replication, just do that and give me the replication, don't point to your notoriously error-prone tools as though they lend your report credence.
It's in a similar vein to people who reply to questions with "well Claude says: <chat transcript dump>"
or substantially worse: "<chat transcript dump>"
If a report is improved and becomes actionable, that's great.
That you used an LLM to "confirm" the bug is an example of such non-information. The reproduction testcase and/or the reproduction steps and description of the expected outcome confirm the bug.
In the state of the tagged video he says still not accepting AI submissions until a certain set of preconditions is met. So... No?
- using the LLM to find (possible) bugs and a human confirms it by testing, reviewing, etc.
- using the LLM to find and confirm the bug without the human confirming it, just trusts and believes LLM
Actually, on second thought, it really doesn't. Indoctrination and herd mentality are quite the things.
https://youtu.be/zwi5b5xSsKA?si=w6zZN6AtIvJS9MxP&t=2084
Just don't be surprised if the project BFDL talks shit about you or your company later.
(Still a good language though, credit where credit is due.)
A simple, "this entity is a sponsor, and therefore there is a conflict of interest and we will not comment on recent controversy" is enough.
If it's big enough, refuse to take further contributions.
I know it's not entertaining, but that's why we have video games.
For some reason--COVID brain rot, poorly-socialized people coming online, general increase in viciousness in the population, who knows!--people have forgotten the utility and purpose of boring polite manners and communication.
I'm looking forward to see what the new build integration can unlock on the tooling side.
What I'm looking for the most for the next release(s):
- New stackless coroutine IO implementation
- First class fuzzer tooling
Outcompetes C even? I'm especially exited for SpirV. Would be great to use Zig for both CPU and GPU programming.
Especially in WebGPU, where WGSL tooling is very early.
It’s not for everyone yet. It’s still unstable, and its ecosystem is small. However, both are improving.
- wasm lalign utility (integrated in opengenepool.vidalalabs.com, not obvious how to trigger it but you can inspect the wasm package)
- real-time DNA gel lane assignment
- proprietary (Claude also used zig to reverse engineer the usb wire protocol) industrial camera driver
Last two:
https://x.com/DNAutics/status/2099583335940936175?s=20
To be fair, I've heard this for years now, yet the hype keeps mounting. I wasted half an hour this morning debugging a broken Zig project, all because I used a release a few months too new that removed some options used in build.zig
Releasing stable software and caring about backward compatibility is a skill many open-source maintainers don't ever want to engage with. It's so easy saying "our code is not stable, if it breaks good luck to you", but at some point it starts to smell like fear of commitment to running a serious project that people depend on.
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.
Background is I created issue and one pull request to fix them in zig compiler version 0.16.1 issue numbers 36812, 36811 (you cannot access them as my account is banned). Respecting the community’s no AI stand. For these specific issues I wrote the issue and code myself and not let AI write it. Spend a lot of time on it. Subsequently without any notice my account was banned because my projects on github using zig uses LLM. This was done without message or any information. My account was banned on zig repository.
I can now understand the other side of coin how bun team might have been treated with disdain when they used LLM.
I wrote an email and left the zig community, have many work in zig but slowly moving them to odin.
I feel personal disdain should not be spilled on to people who are pragmatic on using LLM. I was a very big evangelist of zig for their no LLM stand and promoted them among my community, but with poor treatment by community I just left. You can still see projects I wrote in zig [2].
I have worked with postgreql community since 1997 and python community since 1998. Never felt such hostile community. So all the best and I wish zig continue its progress
[1] https://github.com/insanai/sqlodin
[2] https://github.com/insanai/zenfmt
I have been in open source world with linux kernel since 1992, never every had seen a community so hostile, especially towards humans who spend time and efforts just out of curiosity, inquisitiveness and trying to support some simple alternative when odds are already against them.
Facing hostile behavior from inside the community made me switch to odin language where they also do not use LLM but are pragmatic about people using it. Cannot comment on Mitchell because I do not contribute with money.
[1] https://odin-lang.org/
> my account was banned because my projects on github using zig uses LLM.
Its not Zig. Its codeberg. Codeberg has a strict no-AI policy. Codeberg is ALL about the community and not the lone hacker. I think its a good policy to prevent overload and clearly distinguish project ecosystems from each other.
https://blog.codeberg.org/protecting-our-floss-commons-from-...
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.
[1] https://github.com/insanai/sibuna
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.
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.
Sorry, would you mind clarifying what you mean by this? I'm only aware of the one incident?
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.
"Jarred was already writing slop well before he had access to LLMs."
"Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show"
"When Jarred announced the Rust rewrite, we were ecstatic. It seemed too good to be true. I have to admit, I didn't think the technology was there, to pull off this stunt. But he did it, and now I'm metaphorically sipping delicious tea from a mug that says "It Tastes Like It's Not My Problem Anymore"." [1]
or what about when he called people "monkeys" because he didn't like their product [2]
or when their vp of "community" called github employees clowns [3]
so don't let people tell you that there isn't a pattern here. and when this kind of behaviour comes from the top it shapes the rest of the community
[1] https://archive.is/wNLqY
[2] https://web.archive.org/web/20251127021007/https://ziglang.o...
[3] https://bsky.app/profile/kristoff.it/post/3lwa2whcrj22c
> Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show
Are these claims false, though?
What's this new approach they're trying?
Once that is done, @dnautics is working on memory safety for zig [1]. A Checker for Lifetimes and other Refinement types.
Then we can start the Rust vs Zig Debate again. Hopefully not too late.
[1] https://github.com/ityonemo/clr/
Either Zig gets good enough to be a worthy re-write target, or it doesn't. But I suspect that isn't even what they want.
I imagine languages are going to bifurcate into ones that go all in on agent experience and ones that go all in on human experience. And Zig seems to be in the latter group. I am confident that there will always be some niche market for languages lovingly crafted for humans. But the criteria we will use to define success within these groups of languages will be different.