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>"
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.
Shouldn't everybody already know that while using AI to find bugs for oneself is amazingly efficient, using AI to submit bug reports for others is quite the opposite? Burden of verification and all.
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.
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++.
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 can see my fork at [2]). 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 [3].
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
> 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 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.
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.
Filed a compiler bug related to dwarf tables that screws up debugging and line of code coverage that they completely ignored, just because I mentioned that I had every LLM check it to confirm it's a bug, since all I know is what kcov and every coverage tool generates incorrect coverage data for my repo, for 100% certain.
Can you offer any specifics? The ToC looks quite extensive, which to me indicates a lot of design decisions needed to be made (probably involving many people) and unclear how that process might be accelerated by AI.
Unless you're suggesting the language design should also be vibed together?
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.
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.
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.
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.
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.
Would recommend checking out the Zig state of the (tagged) union as well.
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.
> 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>"
6 replies →
> Is he going to go back and reopen all of those now that he learned what pretty much everyone else already knew?
In the state of the tagged video he says still not accepting AI submissions until a certain set of preconditions is met. So... No?
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.
Shouldn't everybody already know that while using AI to find bugs for oneself is amazingly efficient, using AI to submit bug reports for others is quite the opposite? Burden of verification and all.
1 reply →
There's a difference between Opus 4.5 and Astra 6
6 replies →
citation needed
[flagged]
Warming up to LLMS... explicitly _after_ full branch-coverage and fuzzing.
He'll reevaluate the LLM bug-finding situation in a few years.
https://youtu.be/zwi5b5xSsKA?si=w6zZN6AtIvJS9MxP&t=2084
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.
[flagged]
It boggles the mind that people believe anyone that thinks differently from them is automatically utterly stupid.
Actually, on second thought, it really doesn't. Indoctrination and herd mentality are quite the things.
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++.
I mean. Zig is a really freaking good language for LLMs (in my hands) too
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 can see my fork at [2]). 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 [3].
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://codeberg.org/vyomtech/zig
[3] https://github.com/insanai/zenfmt
> 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 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'm always impressed by Zig's targets support. I'm starting to think that it might be the only language that competes with C on this regard.
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
> competes with C
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.
How is Zig doing as a project? I remember they took a hard line against AI
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.
Ghostty is a strange example though because Mitchell is very keen on agentic engineering.
1 reply →
It looks like they're spending 5 months what should be a 1 month job these days.
Filed a compiler bug related to dwarf tables that screws up debugging and line of code coverage that they completely ignored, just because I mentioned that I had every LLM check it to confirm it's a bug, since all I know is what kcov and every coverage tool generates incorrect coverage data for my repo, for 100% certain.
46 replies →
Can you offer any specifics? The ToC looks quite extensive, which to me indicates a lot of design decisions needed to be made (probably involving many people) and unclear how that process might be accelerated by AI.
Unless you're suggesting the language design should also be vibed together?
15 replies →
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.
Slow and steady wins the race
8 replies →
Im really enjoying using it, works great tbh
Seems to be C++ing which is disappointing. Looking more at C3 and Odin for cases where I'd hoped Zig to land.
Odin scratches this “stick shift” itch for me better than anything else. Highly recommended.
In what sense are the C++ing? Too complicated or what?
can you elaborate on what you mean by "C++ing"?
C3 is honestly so good and a bit underrated.
1 reply →
Curious as to the state of evented IO / io_uring in this version.
Although I understand that upgrading LLVM version is a lot of work, it's a bit frustating that loop vectorization is still disabled.
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.
Thanks for your work btw.
1 reply →
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.
You should not worry. They said they would make a short release cycle for updating to 23.
https://ziglang.org/news/0.17.0-released/
Any change to the AI policy?
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.
> Please consider a recurring donation so that we can offer more billable hours to our core team members.
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.)
I wouldn't consider donating until the project leader has demonstrated considerably more personal maturity.
would you rather the reverse to be true? if someone donates enough that's sufficient for the BDFL to silence their opinions?
yes.
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.
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.
1 reply →
[flagged]