upvote
One non-obvious reason is that an important aspect of their community is to shepherd new contributors [1]. LLMs crushing everything would reduce that. More obvious is all the toil for maintainers dealing with LLM PRs (broadly it’s an issue). The Zig maintainers prefer to put their energy into improving people and fostering those relationship.

[1] https://kristoff.it/blog/contributor-poker-and-ai/

reply
It's important that developers have an accurate mental model of how things work, are structured and why.

LLMs promote a decoupling of mental models and the actual codebase.

As much as some may want to believe, just reviewing what the LLM outputs is not equivalent to thinking about implementation details, motivations, exactly how and why things are, and how and why they work the way they do, and then writing it yourself. The process itself is what instills that knowledge in you.

reply
Well said! I don't think either party is really at fault here, but if Anthropic wanted to contribute non-negligible amounts of code over time then it's an absolute dealbreaker.

Sucks for people who were invested in contributing to Bun and don't like working with AI tools to be sure, but I think the writing was on the wall for them pretty much immediately post-acquisition. You must admit, it's hard to predict that 100% of source lines will be written by AI if you're not walking the walk!

reply
Yeah, I remember when the lazy bastards started writing programs using compilers instead of learning assembly language. Now I don’t have a single colleague who can write assembly. There’s whole generations now who can’t code assembly. Most don’t even know what a register is. Hope Zig holds against this latest attempt to make everyone stupid.
reply
To add to the other commenters, loads of people don’t know assembly, which speaks to the quality of the average developer. The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.
reply
I'd be very surprised if the "average" developer across the board was in fact not just a JavaScript / TypeScript only developer. I have no expectations or really even hope that the average developer I work with has ever written a line of assembly.
reply
>The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.

That is if you use something like C, C+=, Java, .NET, Go. With Javascript and Python I don't think knowing assembly would make any difference because it's hard to optimize the code in these languages for how the CPU and memory works.

reply
Knowing assembly in this day and age is the result of being curious and wanting to understand how computers work, which means knowledge of algorithms, data structures, etc.

The same applies to vibe coding: the best "vibe coder" will paradoxically be the person with enough knowledge and curiosity to understand programming, how computer works and the subject at hand; one that could write the whole thing from scratch so they have enough judgement to review generated code.

Of course the vast majority will be mediocre vibe coders, and even worse programmers; at least that's the direction we're going.

reply
Knowing assembly doesn’t mean you would spend your time writing assembly (aka being familiar with opcodes and architecture optimizations). But in the process, you get familiar with the working of the computer hardware and the OS that sits on top of it. That is always useful knowledge especially when needing to deal with binary format and protocols or FFI.
reply
Generating AI code/PR is not the same as using compilers because of at least two things:

- the scale of how much and how fast you can generate code with AI vs how fast can you write code for compiler

- the mental model of what is being generated and how much the contributor understands and owns the generated code

reply
Using an LLM isn't analogous to using a higher level language.
reply
That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic. That may be a problem but it’s still a higher level language, just a much higher level language than anything before.
reply
I assume you're some sort of programmer and I genuinely wonder how in the world can someone in good faith downplay non-determinism and ambiguity when talking about a programming language.

High-level languages can certainly yield inefficient code when compiled, or maybe different code among different compilers, but they're always meant to allow their users to know exactly what to expect from what they put together in their programs. I've always considered this a hard fact, I simply cannot wrap my head around working in a way that forces me to abandon this basic assumption.

reply
So by your logic all the PMs, managers and customers are programmers, right? After all, there’s a human compiler that takes their input and produces a program?
reply
They are programmers when they write a prompt and get runnable code as a result, yes… but no if asking a human to write the code because if you have an intermediate, manual step between the text and the running code, you don’t have an automated process and hence it’s no longer even an application, let alone a “compiler”.
reply
The main difference is that the input to an LLM is in an ambiguous language.
reply
A programming language is allowed to be ambiguous, I don’t know of a definition that excludes that!
reply
All programming languages I know of provide at least some guarantees about the program’s behavior.
reply
The language specs may be, but an implementation is never ambiguous. When you encounter and undefined behavior in the specs, that’s when you look at your compiler/interpreter docs.
reply
So is JavaScript haha.
reply
> That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic.

So it is not, by your own admission, "exactly, literally the same".

reply
Take it gently, the poor thing doesn't understand the difference between code and talking about code.
reply
Your analogy falls apart because the "lazy bastards" still knew how to program and understood the code they were working on.

Vide-coders often don't read, let alone understand, the code they send for PRs.

reply
I don't think most JavaScript devs know how to read C code, let alone assembly, so I think the comparison is apt. Is it not?
reply
The JavaScript developers are checking in JavaScript code that they ostensibly understand. That is not the same as prompting an LLM to generate Zig that they don't understand, and expecting someone to merge it.
reply
There’s a big difference between (mostly) deterministic compiler and non-deterministic LLMs.
reply
That's a solid reason to keep LLMs away from the kind of tasks that help with onboarding. But a patch series from a competent team that changes 3000 lines should probably be evaluated on its own merits. Or at least, the collaboration-based reasons to reject AI don't apply and the real reason would be something else.

(Though I don't know if this particular patch series would get accepted on its own merits.)

reply
The recent article explained the bun patch would have been refused on technical merits as it's intrinsically incorrect, to be able to work properly it required some language changes.
reply
> patch series from a competent team that changes 3000 lines should probably be

split into a bunch of much smaller changes?

reply
I don't understand your suggestion. If you take an ugly patch series that changes 3000 lines and organize it into small quality changes, it's still a patch series that changes 3000 lines.

There's no reason to assume my generic statement was talking about the ugly version rather than the nicely organized version.

reply
perhaps not all of these 3000 line changes make sense?
reply
I mean in an authoritarian system you wouldn’t make a one off exception like that.
reply
There are other reasons why a project like Zig might not want to accept LLM generated contributions.

Zig, as programming language, has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will, as it's a fundamental building block of everything that uses Zig. Just that could be worth the extra scrutiny on every individual commit.

There's also the usual arguments: copyright ethics, environmental ethics and maintainer burden.

reply
> has a multiplier codebase. A bug may affect a significant larger portion of users than most libraries or binaries will

Couldn't you say exactly the same about bun?

reply
Sure, but Bun is now owned by a company who's entire shtick is creating AI models. That shifts priorities.
reply
It might be one of the reasons they want to migrate to Rust, i.e. to handle many these memory related issues by the compiler. Personally I used bun on a very few personal instances. But if you check issue reports, you will see memory bugs being reported say more than deno.
reply
The LLM rule has been a thing for a very long time at this point.
reply
>Makes me wonder why zig announced the strict LLM rule recently.

I guess there are 2 philosophies in software development: move fast and break things and move at a pace that guarantees everything is rock solid.

Most commercial software, Anthropic included is taking the former path, while most infrastructure teams are taking the later.

I guess Linux and FreeBSD kernels are also not accepting LLM based contributions yet.

reply
> I guess Linux and FreeBSD kernels are also not accepting LLM based contributions yet.

PostgreSQL, a famously slow and rock solid project, accepts LLM-based contributions. But they are held to the same high standard, if you cannot explain the patch you submitted it likely get rejected.

reply
> move fast and break things and move at a pace that guarantees everything is rock solid.

Zig is famous for taking the former path! Anyone using Zig for a few years knows every release breaks things, and they are still making huge changes which I would classify as “moving fast”, like the recent IO changes!

reply
Exactly, and Zig 0.16 is explicitly a release with known issues, just count the number of TODOs in the std.Io namespace.
reply
> I guess Linux and FreeBSD kernels are also not accepting LLM based contributions yet.

Both appear to be[1][2]. FreeBSD doesn't have a formal policy yet, but they appear to be leaning towards admitting some degree of LLM contribution.

[1]: https://docs.kernel.org/process/coding-assistants.html

[2]: https://forums.freebsd.org/threads/will-freebsd-adopt-a-no-a...

reply
Possibly, but the Zig creator is active on Lobste.rs, where he's been vocally anti-LLM for a year now, so the timing could just be a coincidence.
reply
It's a combination of pragmatism (not wanting to wade through slop, not wanting to shove out newbie developers) and politics (usual contemporary techie progressive stuff that's now oddly anti-technology).
reply
> usual contemporary techie progressive stuff that's now oddly anti-technology

You can be against a particular technology without being "anti-technology".

See DRM/surveillance/bad self driving implementations.

reply
> usual contemporary techie progressive stuff that's now oddly anti-technology

Just because a thing exists doesn’t mean you have to use it for everything. You don’t use asbestos blanket? Why are you so against asbestos?

reply
Against blankets would be even more like that argument.
reply
deleted
reply
deleted
reply
I like your username.
reply