Top
Best
New

Posted by SergeAx 7 hours ago

Bun is being ported from Zig to Rust(github.com)
434 points | 297 commentspage 2
padjo 3 hours ago|
Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.
xigoi 1 hour ago|
> Picking a pre 1.0 language to build your product always seemed like a bad choice to me.

Such as React Native? :D

jr-14 7 hours ago||
I want zig to succeed but given that zig is not yet 1.x I'd imagine a large code base like bun would have difficulties addressing major breaking changes. Also given the fact that bun is using a fork of zig https://x.com/bunjavascript/status/2048427636414923250?s=20
rollulus 2 hours ago||
Rewriting it using an LLM is one. But did all the contributors became as proficient in Rust as they were in Zig over night as well?
wongogue 2 hours ago|
They are owned by Anthropic. They have virtually unlimited Claude credits.
lionkor 1 hour ago||
Tell me you've never worked with system languages without telling me you've never worked with system languages (telling claude to "write it in Rust" does not count).
Humphrey 7 hours ago||
I'll be very interested in how this AI port turns out. I am involved in a number of active projects that are being held back by the language / framework is holding back the project, but where a rewrite would be too big of a project to undertake by using only human power.

I've had more success vibe coding Rust than I have in more dynamic languages. I suspect the strictness of the Rust compiler forces the AI agent to produce better code. Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job.

jillesvangurp 1 hour ago||
I've been targeting Go instead of Rust for a few things. But same deal, I'm not really a Go programmer and it seems to work well enough. I do have a few decades of engineering all sorts of code bases; so I'm not coming at this completely naively.

My way of compensating for my own inability to do detailed code reviews is making sure the tests, integration tests, end to end tests, cover everything I care about. Without that, you can't be sure it is not skipping detail work. I've also made it do some bench marking and stress testing and then analyze the code base for potential bottlenecks. After it found and fixed a few issues, it got better. Finally, prompting it to do critical reviews, look for refactoring opportunities, etc. can give you a nice list of stuff to fix next. Having it run memory leak checkers and static code analysis tools also is a good strategy. Once you start running low on issues you find this way, the code is probably not horrible. Or at least you hit some sort of local optimum.

The lack of code reviews sounds pretty horrible. But it is now quickly becoming the biggest bottleneck in AI assisted coding. Eliminating that bottleneck is scary but it enables a few step changes in volume of code that becomes possible. Using strict compilers and strict memory management helps eliminate a few categories of bugs and issues.

I was previously doing this with languages I do understand. Once you start routinely dealing with larger and larger commits, reviews become a problem.

I expect working with larger code bases like this will get a lot easier and better over time. I noticed that the main headaches I face with this type of engineering are the tendency of models to keep deliberately cutting corners, only doing happy path testing, or deferring essential work for later. I suspect a lot of the models are simply biased to conserving token usage. Pretty annoying but also easy to compensate for with follow up prompts and testing. And probably something that becomes less of an issue as the models get tuned to behave better without additional prompting.

moomoo11 2 hours ago|||
> It could be just that I am less familiar with Rust so it feels like it's doing a better job.

Dunning Kruger effect. At least you admit it.

raincole 2 hours ago||
This is pretty much the opposite of Dunning Kruger effect.
rustybaritone 5 hours ago||
Yes it generates trash Rust code.

> Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job.

Ya think?

fgfarben 5 hours ago||
Doy!
bijowo1676 3 hours ago||
Its never been easier to rewrite X in Rust than today.

Will everything eventually be rewritten in Rust and we finally achieve utopia?

vrighter 1 hour ago||
why would we need to rewrite twitter in rust? (sorry, couldn't resist)
zelphirkalt 2 hours ago||
... or will it all rust away?

OK I'm sorry, I'll see myself out.

wg0 5 hours ago||
If nothing, it'll be good marketing material targeted at non-technical enterprise executives so that they pressurize their engineering teams in meetings that look people are porting such complicated things from one different language to totally different language then why are we not using AI effectively?!
yladiz 7 hours ago||
Why? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?
_--__--__ 7 hours ago||
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.
kristoff_it 6 hours ago||
Code origin was not even a factor https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
_--__--__ 6 hours ago||
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.
kelnos 3 hours ago|||
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.
croes 5 hours ago|||
I wonder if they didn’t consider the problems of their changes in Zig what else do they not consider in Bun
nikeee 7 hours ago|||
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.

nullstyle 7 hours ago||
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.
reissbaker 7 hours ago|||
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.
toshinoriyagi 3 hours ago|||
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...

andriamanitra 2 hours ago||
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

philwelch 6 hours ago|||
Also, if Zig itself doesn’t accept AI contributions, it’s probably NGMI unless somebody is willing to maintain that fork.
tom_ 6 hours ago|||
If the computer can do it for them, then why not?
sourcegrift 7 hours ago||
[flagged]
IggleSniggle 6 hours ago|||
Source?
philwelch 6 hours ago||||
Normal, emotionally stable people don’t care if the creators of a programming language disagree with them about tariffs.
kelnos 3 hours ago|||
I can't find any evidence that the creators of Zig hold the views GP seems to suggest, but I think your assertion is wrong.

Normal, emotionally stable people do sometimes make decisions about what businesses to patronize based on the political leanings of the business owners. Same thing happens with art appreciation, movie/TV watching, and plenty of other things. Zig might not be a business, but the same rules apply.

You may think that's foolish, and not make your decisions that way, but it's a perfectly valid way to make decisions.

vips7L 6 hours ago|||
Normal, emotionally stable people don’t drive business towards people they disagree with politically. You see that all around the country.
heldrida 6 hours ago||||
Absolute nonsense. Why are you creating rumours?
philwelch 6 hours ago||
Why would someone make up such a banal rumor? I’m not saying it’s true, I’m saying who cares?
tipiirai 6 hours ago|||
Really? Do you have a source?
hbbio 6 hours ago||
Given they have "unlimited" AI usage, do we expect the port to be complete tomorrow?
elffjs 6 hours ago||
Comparing this claude/phase-a-port branch with main: “Showing 1,646 changed files with 773,950 additions and 151 deletions.”
jedisct1 1 hour ago|
And of course, everything was carefully reviewed by a human.
inkysigma 7 hours ago|
So I can't tell if the linked commit is an actual attempt or just an experiment but it did always strike me as odd to make a JS runtime in Zig when my impression was there were a lot of work-stopping compiler bugs at the time.
ivanjermakov 1 hour ago|
Considering no public announcement this is just an experiment, possibly leaked.
More comments...