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.)

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!

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.

> 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?

> 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!

> 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...

I like your username.

I was hoping bash because why not. It's AI that has to work and maintain anyway and Anthropic employees aren't limited by 5 hour 7 days limits anyway I suppose.

Downside: CC and Codex will write, compile, and fix in a loop until it has a monstrosity rather than designing something smarter.

This could be a subjective feeling with no real data to back it up.

People say same about Go as well that it's type system and limited feature set makes it the best AI friendly language but there too, it just seems like a hunch rather than a proven fact.

Excellent comment.

As a downside, the compile time is somewhat offset once you're using agents (and especially parallel agents) anyway. Since all of your edits cost a round-trip API call to a third party server, you can accept a slightly slower compile step.

Interesting experiment, would it actually function if Zag was syntax/api locked to Zig? I guess Zag could still have api extensions.

It's time!

https://xkcd.com/286/

It was and is a perfectly good term, but people started using it without regard for its definition. I don't know why people wouldn't misuse a "better" term the same way.

i mean AI docs are usually the result of collabs between users and AI using /plan

with superpowers, i see a lot of specs -> impl plan -> execute plan

You're already at a disadvantage having to stuff the context and spend extra tokens coercing the model in the correct direction compared to it already knowing what to do (rust, ts, go, etc.)

Here, I just did a quick test with claude.

1. "make a simple tcp echo server that uses rust"

compiles and runs - took a few seconds to generate.

2. "make a simple tcp echo server that uses zig"

result: compile error, took literal minutes of spinning and thinking to generate

response: "ziglang.org isn't in the allowed domains. Let me check if there's another way, or just verify the code compiles conceptually and present it clean."

/opt/homebrew/Cellar/zig/0.15.2/lib/zig/std/Io/Writer.zig:1200:9: error: ambiguous format string; specify {f} to call format method, or {any} to skip it @compileError("ambiguous format string; specify {f} to call format method, or {any} to skip it"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3. "make a simple tcp echo server that uses zig 0.16"

result: compile error:

zig build-exe main.zig main.zig:30:21: error: no field named 'io' in struct 'process.Init.Minimal' const io = init.io; ^~

4. "make a simple tcp echo server that uses zig 0.15"

result: compile error

zig build-exe main.zig /nix/store/as1zlvrrwwh69ii56xg6yd7f6xyjx8mv-zig-0.15.2/lib/std/Io/Writer.zig:1200:9: error: ambiguous format string; specify {f} to call format method, or {any} to skip it @compileError("ambiguous format string; specify {f} to call format method, or {any} to skip it");

Rust took seconds and just works. Zig examples took minutes and don't work out of the box. The DX & velocity isn't even close.

There is like 1,713 open PR's on the Bun repo. I'm assuming all are from Claude or robobun?. I guess this gives us an insight on what the claude-code workflow look likes. Crazy times.

Where is a source for either of these extraordinary claims?

Anthropic only acquired Bun in December of last year. They weren't there in the first place, to make the decision.

Anthropic makes claude, claude can write Rust like a champ and struggles at Zig. It's a straightforward "training data" argument.

I think there are even longer term plays that Anthropic should be looking at, in this space, but it seems like they've decided rust is the right thing, so fair play. I would be (am!) thinking about making an LLM optimized high level language that you can generate / train on intensively because you control the language spec.

I'm reminded of the old joke "how to shoot yourself in the foot in 25 different languages". The first one was "C - you shoot yourself in the foot." Zig remains very close to that philosophy.

So the difference is not in writing new stuff but in maintaining the existing codebase. Rust's rigidity makes it potentially harder to break stuff compared to Zig's general flexibility. As a project grows and matures, different types of contributors naturally come in and it's unreasonable to expect everyone to learn about historical footguns that may have accumulated.

fwiw before today I'd heard of Zig and not Bun :D

something JS-adjacent could certainly be more known than an obscure language but are that many people using drop-in node replacements?

They do work well. But I still see the occasional type related issue or bug from refactoring that claude will introduce into javascript and python code. It seems to be happening less and less frequently as the models get better. But, the rust compiler catches real bugs in LLM code. I consider that a win.

Has anyone made any cross language benchmarks for LLMs? I wonder if rust's conceptual complexity makes it harder for LLMs to write? If all you care about is working software, which language is best for LLMs? Python, because there's more example code? Go or Java, because they're simpler languages? Ruby because its terse? Rust because of the compiler? I'd love to see a comparison!

You're right, all 750k lines of code added in a single day - definitely reviewed and completely understood.

Here is the Wiktionary definition for curiosity.

> (programming, neologism) A method of programming in which a developer generates code by repeatedly prompting a large language model.

https://en.wiktionary.org/wiki/vibe_coding

The dilution of the term is a real problem sometimes.

But pointing your AI at an entire codebase to transpile pretty much entirely by itself? Yeah vibe coding is a fitting term.

Even if you wrote it a small essay on how to Rust. That improves the situation but doesn't change the core autonomy/hope of the task.

This is just a coined term; definitions evolve over time based on usage

The question isn't whether or not you'd get the same line count with a non-LLM tool. The question of whether or not it's vibe-coded depends on whether or not the committer actually reviewed and understood the new code. And with a 75k line difference, that seems unlikely.

I use to do this and then do test manually to validate everything works as expected in my small open source project. But then over the time I saw that some bugs crept in which I was unable track since I was doing manual testing. So I wrote some e2e tests with playwright and I think that gives a bit relief (at least).

It really isn't if you don't have the right abstractions.

Especially for memory management the right and wrong abstractions in Rust can lead to a factor of 5 or 10 extra amount of difficulty. The right memory management abstraction and your code can be a straight line port (or even cleaner!), the wrong one and you're going to just be spending a lot of tokens to have a machine spin around in circles trying to untie itself

GC'd languages don't have this problem, though obviously you can still generate stupid amount of pain for yourself by doing something wrong

I'm porting a large-ish delphi application to c sharp. It's been pretty hands-off except for converting to async and some language capability mismatch.