Hacker News Reader

Comment by yladiz | Hacker News Reader

Why? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?

Possibly related to https://simonwillison.net/2026/Apr/30/zig-anti-ai/ where the Bun team wanted to upstream work to Zig that was rejected by a blanket anti-LLM contribution policy.

Code origin was not even a factor https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

That seems totally reasonable but I wonder if there was some head butting in non-public channels given Bun is one of the biggest players in Zig and planned to push through a change like that on their own.

I wonder if they didn’t consider the problems of their changes in Zig what else do they not consider in Bun

Even if there was anything in private channels, the reasons stated in that forum post are alone more than enough to reject Bun's Zig changes.

And also great reasons for Bun to port themselves elsewhere. If they aren’t allowed to contribute to Zig, there’s very little reason to select Zig moving forward.

It's not that they were not allowed to contribute. If you read the ziggit link up thread it becomes clear why their solution was simply wrong.

Zig is a moving target that has breaking changes in every release (which is fine as they are sub-1.0). But that means that AI tools have been trained on outdated syntax/etc. Zig isn't that common, so there is even less training data to begin with.

Rust on the other hand is pretty established by now and has less breaking changes. It also has more compile-time safety-guarantees that makes vibe-coding a bit more confident.

In top of that, Zig has rejected their upstream contributions. So they'd have to maintain their own compiler in the long run, which is probably just technical debt to maintain.

Most of my vibe coding is in zig, and it has been my experience that Claude and Codex both keep up with zig changes just fine. Every now and then I catch them writing outdated code that they burn some tokens on, but my experience says your local codebases’s idioms will influence what gets generated enough to stop this from being a problem.

Is there even breaking change in Rust after 1.0?

Probably an experiment due to Bun's PRs to Zig being rejected (Zig does not allow AI use). If Rust works well enough, and the alternative is maintaining a fork of Zig, I'd guess they'd go with Rust.

Also, if Zig itself doesn’t accept AI contributions, it’s probably NGMI unless somebody is willing to maintain that fork.

The anti-AI policy had nothing to do with Bun's PRs being rejected. This post[0] by a core zig maintainer explains why the PRs were low quality and subsequently rejected.

[0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Was there even a PR? The post from Bun [1] says they have no plan to upstream it, and that ziggit post says the changes are undesirable. It sounds like there never was anything to reject.

[1] https://x.com/bunjavascript/status/2048428104893542781

If the computer can do it for them, then why not?

Reply on news.ycombinator.com