Man what a waste of electricity. Now there's a PR filled with so much crap nobody can review it, which means bugs will absolutely be introduced. For what?
Man what a waste of electricity. Now there's a PR filled with so much crap nobody can review it, which means bugs will absolutely be introduced. For what?
They're doing the rewrite because they frequently have bugs caused by memory safety issues, which Zig, like C and C++, does not have good protections against. It's true that this rewrite has a lot...
They're doing the rewrite because they frequently have bugs caused by memory safety issues, which Zig, like C and C++, does not have good protections against. It's true that this rewrite has a lot more usages of unsafe blocks than most Rust projects, but it's a huge improvement from all the code effectively being inside an unsafe block as before, they're manually cutting down on many unnecessary unsafe blocks, and any new code that's written as idiomatic Rust from the start should be free of new memory safety issues.
It's a file-for-file conversion. The new codebase will be very similar in structure and control flow to the old codebase. It's likely not very idiomatic Rust, but it's not as if they vibe coded a...
It's a file-for-file conversion. The new codebase will be very similar in structure and control flow to the old codebase. It's likely not very idiomatic Rust, but it's not as if they vibe coded a million lines without any review. It should be familiar for any existing contributors.
They also have a very clear picture now of where the unsafe keyword is used, and can target those areas for improvement. Rust offers a lot of assurances that Zig did not. There's likely some edge cases still to shake out, but I expect it's no buggier than the code that came before.
In theory, yes, but the small amount of a couple of files that I've seen, I think the new codebase would need a lot of care and attention to be useable by human contributors. There are lots of...
In theory, yes, but the small amount of a couple of files that I've seen, I think the new codebase would need a lot of care and attention to be useable by human contributors. There are lots of weird things like the LLM inlining imported functions from other files, resulting in duplicated, subtly different functions lying all over the place; or the LLM writing functions that made sense in Zig but don't make sense in Rust. The result feels fairly chaotic, I don't think any developer is going to be familiar with the new codebase.
I also am unsure about the unsafe keyword issue. One of the dangers of improper use of unsafe is that it can do spooky action at a distance - code that is marked as unsafe may run fine, but it may result in data that violates an invariant somewhere else. So now seemingly safe code is implicitly unsafe. If you're careful, you can build data structures that enforce the right invariants, meaning that the unsafe logic is confined to a certain spot. But it doesn't seem like the Bun uses of unsafe do that. I suspect untangling this amount of unsafe is going to be a very difficult challenge.
There's also the issue that LLMs might but be as good at rewriting or porting as they appear at first glance. A while back, someone wrote a Python HTML5 parser, and other people vibe-ported it to other languages. Except the ports did weird things - they all had subtly different algorithms for some of the internal parts, even though they had all ostensibly come from the same code suggesting the LLM basically wrote its own version of some of the code, rather than doing a straight port. These sorts of subtle issues are difficult to notice at the sort of scale of this PR.
The final issue is that the code the came before was very buggy - that's supposedly why they made the change. And in theory that makes sense - before there were a bunch of memory safety issues, Rust solves (insert asterisk here) memory safety, so switching to Rust should help a lot. But other Zig projects have not been struggling as much as Bun has with memory safety, so I don't think it's so simple to say that Bun's previous issues were because Zig is too lax, and Rust will solve them. Rather, I suspect Bun's previous issues have not to do with issues with how Bun is being developed, and that switching to Rust won't resolve those underlying issues at all. Instead, you're just going to end up with different categories of bug that Rust doesn't do anything to prevent.
All valid points. Notably I'll agree that I have seen LLMs reimplement something without additional prompting, just as a matter of course. Strong enough tests would help mitigate that, as the...
All valid points. Notably I'll agree that I have seen LLMs reimplement something without additional prompting, just as a matter of course. Strong enough tests would help mitigate that, as the behavior should at least match, but it's unlikely to account for all scenarios.
I think these devs are looking at a lot of work no matter what. A ground-up rewrite would have likely taken years of dev hours to get to the same point that Zig-Bun was at, but a full conversion will still require months-to-years of review to check everything for correctness.
The third option - to continue on with Zig likely wasn't ideal either. I don't know if they're overstating the memory issues to justify the port, but I imagine there's other difficulties of using off brand languages that they've run into.
I suspect, considering the current paradigm shift in software engineering right now, that the economics of these decisions may be rapidly changing. It may be less about the scope of the work, and more about the capability of the models themselves. Are they better at writing code, reviewing it for correctness, reshaping it for idiomatic style, or discovering memory bugs?
It's an interesting experiment, if nothing else. I expect a lot of large tech companies are considering a similar project. Memory issues are still the number one killer, and I can imagine a lot of engineers salivating at the idea of a 100% Rust codebase. Maybe we'll see Google Chromium or even the Linux kernel making the same move in a couple of years.
I'm not sure the economics are changing so much. Firstly, LLMs are getting more expensive as the major providers stop subsidising their usage (see Anthropic's recent terms of use changes, and...
I'm not sure the economics are changing so much.
Firstly, LLMs are getting more expensive as the major providers stop subsidising their usage (see Anthropic's recent terms of use changes, and GitHub's big price increases). Bun could do this because they're owned by Anthropic and basically have access to unlimited Claude usage for free (and possibly even the new Mythic model?).
Secondly, most big projects in memory-unsafe languages don't suffer from bugs to the extreme extent that Bun has. Yes, there's good reason to push for more usage of memory safe languages in critical parts of core software like browsers or the kernel, but there are also a bunch of other tools that can at least partly mitigate issues. But Bun has always been buggy beyond just that. And maybe it's because Bun has unique challenges that make it harder to get memory safety right than in, say, Tigerbeetle or Ghostty or whatever else is using Zig, but I don't think most other projects are going to get as much value out of a rewrite.
And thirdly, the proof is going to be in the pudding. It's not enough to spend vast numbers of token generating a new version of Bun - they also need to prove that the new version is materially less buggy. They've not really done that yet. In fairness, this is just an initial port, and there's a lot that needs to be cleaned up from this point in, but like I said before, I don't think Bun is buggy because of memory safety, I think it's buggy because it's not very good. So I suspect we're just going to see memory safety issues and segfaults going down, but there's just going to be other bugs instead that make up the balance. That is, for an end-user of Bun, I don't think there's going to be much difference.
Just want to push back on this a bit. It is true that token costs from the large providers typically increase with new models, the cost per "intelligence" has been going down. This is most obvious...
Firstly, LLMs are getting more expensive as the major providers stop subsidising their usage
Just want to push back on this a bit. It is true that token costs from the large providers typically increase with new models, the cost per "intelligence" has been going down. This is most obvious from OpenAI, where GPT 5.5 is cheaper than 5.4. If you need intelligence equivalent to 5.4 xhigh, 5.5 medium gets you the same result with lower token usage and lower costs. Anthropic is less of a clear win, but Opus 4.7 is both more intelligent and cheaper than 4.6. If you include the fact that Chinese open weight models are typically right behind western models and significantly cheaper to run, the cost future looks even more promising. If you stabilizes your needs on a set "intelligence" level, your costs will go down over time.
I mean more in the sense that a lot of companies right now seem to be relying on subsidised inference - see Claude's subscriptions where loopholes are being slowly tightened, or GitHub Copilot's...
I mean more in the sense that a lot of companies right now seem to be relying on subsidised inference - see Claude's subscriptions where loopholes are being slowly tightened, or GitHub Copilot's subscriptions which has recently become significantly more expensive. I think in the long term you're right, but I think in the short and medium terms, companies are typically going to end up paying more than they are currently, at least for developer tasks like this one.
Those graphs are based on API pricing which has not changed or increased. Companies use API pricing, not subscriptions. Chatgpt itself doesn't even have the 100 and 200/month plans for business.
Those graphs are based on API pricing which has not changed or increased. Companies use API pricing, not subscriptions. Chatgpt itself doesn't even have the 100 and 200/month plans for business.
The companies I've been working with have basically all used either GitHub Copilot or Claude. API pricing has mostly just been used for the occasional integration (i.e. when building a tool that...
The companies I've been working with have basically all used either GitHub Copilot or Claude. API pricing has mostly just been used for the occasional integration (i.e. when building a tool that has AI integration, use API pricing for that integration, but for the actual programming of it use Copilot/Claude subscriptions).
In fairness, these have mostly been smaller companies (<100 developers) and I can imagine things are different for bigger corporations.
That's true. Chrome has MiraclePtr, for instance, and some very extensive fuzzing suites. They also have the Rule of 2 to avoid the most common pitfalls. But it's a careful balancing act, and...
Yes, there's good reason to push for more usage of memory safe languages in critical parts of core software like browsers or the kernel, but there are also a bunch of other tools that can at least partly mitigate issues.
That's true. Chrome has MiraclePtr, for instance, and some very extensive fuzzing suites. They also have the Rule of 2 to avoid the most common pitfalls. But it's a careful balancing act, and likely introduces a lot of friction compared to just writing code in a memory-safe language to begin with.
On the topic of economics, I'm not sure what to think. It does seem that even the SotA models only have a few months lead. Deepseek, Kimi, GML and others are right behind Claude and OpenAI. And with the ongoing advances that make this tech more accessible to local hardware, I think it's more likely than not that it will be commoditized at some point.
I agree that Bun likely had a number of issues besides memory safety, and this change won't have any effect on those. I will be curious to see how things shake out in the coming months, though. It could be a big mistake. It could be a sign of things to come.
You make some good points. Definitely using Rust was a good call. But I have to add, it will definitely be buggier, less idiomatic, less elegant and more bloated than before. That's just where LLM...
You make some good points. Definitely using Rust was a good call. But I have to add, it will definitely be buggier, less idiomatic, less elegant and more bloated than before. That's just where LLM coding agent technology is right now. It's not as if being under the Anthropic umbrella gives them magical powers to make agents perform better. Look at how buggy, verbose and convoluted Claude Code is. It would be different if it was human led with AI assistance rather than just letting the agents churn... but it doesn't sound like that's how they did it given the short timeframe.
Caveat: if they used Mythos and it's lightyears ahead of Opus, maybe it's better than I'm imagining. I'd say that's somewhat unlikely.
Whatever the case, Claude Code and Codex, despite their issues, have proven that you can ship messy, vibe coded software and people will use it. Vibecoded doesn't mean the new Bun won't be successful.
I expect they probably are using the best model available under Anthropic, whether that's Mythos or some variant. But even then, it can't be better than a 5-10% improvement over publicly-available...
I expect they probably are using the best model available under Anthropic, whether that's Mythos or some variant. But even then, it can't be better than a 5-10% improvement over publicly-available models. I doubt there's any real magic sauce there.
However, I still feel there's a large difference between converting existing software to a new language, and writing software from scratch. Starting a new project requires a lot of design decisions upfront such as overall infrastructure and scope, where to apply abstractions, and what assumptions can be made. Somebody prompting "make me an X" isn't addressing any of those considerations.
A project built in Rust will likely have different considerations from a project in Zig, but they're not so wildly different as to be incomparable. If it makes sense to abstract a function in Zig, it probably makes sense to do it in Rust. Some of the specific language writing will probably feel "weird" and non-idiomatic, but not broken. Refactors can help address those areas in the future.
I'll mention that transformers were originally designed specifically for language translation, for applications like Google Translate. They manage very well at that task, and that's with all the messy complexities of human language. Programming languages are considerably more logical and well-defined, which makes them even better candidates for language translation/conversion tasks.
So this may be vibe coded in the strictest sense of the term, but I'd guess the quality is still reasonably high. Something like Claude Code is a rather different beast. It's been hacked on by many individuals, and has gone through constant changes in scope and direction. That can be the real quality killer.
The thing about tests... When the model hits a failed test, or a parse error, or otherwise unexpected behavior, it starts making decisions, and if you've ever used a coding agent on anything...
The thing about tests... When the model hits a failed test, or a parse error, or otherwise unexpected behavior, it starts making decisions, and if you've ever used a coding agent on anything non-boilerplate you know exactly what those decisions look like.
A lot of times they're ok, sometimes they're great, but sometimes they're incredibly bad. An extensive test suite and the code in another language can reduce that problem but not eliminate it. When you have as much code as they just vibed... I really don't envy the maintainers. There's going to be a strong incentive to slam the hood back down and have agents do the work going forward. Plus they're in Anthropic's world, everything is vibecoded, so there's a cultural incentive too. It may not be Claude Code yet, but it's already on the path.
Note that I'm not making any predictions, a year ago I wouldn't have bet on Claude Code being anywhere close to maintainble at this point and it's still going strong. It ain't pretty, but millions of people use it every day anyway.
So, when Bun was created, they very loudly chose for Zig over Rust, because it gave them the memory control they needed for their very high performance standard. And fair enough: this is one of...
So, when Bun was created, they very loudly chose for Zig over Rust, because it gave them the memory control they needed for their very high performance standard. And fair enough: this is one of the main selling points of Zig and something Rust is explicitly not designed for (not as a main goal anyway).
And now, they come out with a fully generated AI PR, completely unreviewable code, probably also AI slop, saying: yeah, we didn't need that control after all, Rust is actually better because it gives more memory safety.
This was clear from the start, why did you suddenly change now? Was it because Zig was the language of the day at the time? The whole thing just makes me doubt about their initial reasoning, their ability to use AI responsibly and also makes me worried about Astral/UV and OpenAI.
It's pretty clear that they abandoned Zig because of the Zig project's scepticism about vibe coded slop. This whole saga started when they submitted a giant AI-coded PR to Zig, which got rejected...
It's pretty clear that they abandoned Zig because of the Zig project's scepticism about vibe coded slop. This whole saga started when they submitted a giant AI-coded PR to Zig, which got rejected for a variety of reasons - all of which seemed pretty reasonable to me. Someone clearly got annoyed by that and decided to try to cut ties.
What happens outside the zig compiler project does not matter whatsoever. I don't recall it being all that big (maybe we're thinking of different PRs.) I do remember looking at it, and — whether...
It's pretty clear that they abandoned Zig because of the Zig project's scepticism about vibe coded slop.
What happens outside the zig compiler project does not matter whatsoever.
This whole saga started when they submitted a giant AI-coded PR to Zig.
I don't recall it being all that big (maybe we're thinking of different PRs.) I do remember looking at it, and — whether AI or not — it just didn't seem to align with the core team's direction / approach to improving compiler performance.
I think that tweet was posted in bad faith, I don't think it would have been merged to begin with.
Maybe, yes. I agree with that Rust probably would've been better for this particular usecase, from what I can see at least. I don't know if it was stupid though, there are certainly legitimate...
Maybe, yes. I agree with that Rust probably would've been better for this particular usecase, from what I can see at least. I don't know if it was stupid though, there are certainly legitimate reasons to use Zig and some projects use it with great success.
Wow that’s a huge PR! GitHub comments (just GitHub in general I guess) are really struggling to load right now, but judging from the tags here it seems the rewrite is heavily AI-assisted? Perhaps...
Wow that’s a huge PR! GitHub comments (just GitHub in general I guess) are really struggling to load right now, but judging from the tags here it seems the rewrite is heavily AI-assisted? Perhaps entirely done by AI agents?
This is not wrong, but I do want to be clear that a huge reason this was so successful is because of a very well written and detailed test suite. AI works wonderfully when it can determine its...
This is not wrong, but I do want to be clear that a huge reason this was so successful is because of a very well written and detailed test suite. AI works wonderfully when it can determine its wrong, and it can't flub the test.
It's fun going through my company's codebase and seeing tests that amount to: int var1 = some_default_value; int var2 = some_default_value; assertEquals(var1, var2); Glad we use up valuable CI...
It's fun going through my company's codebase and seeing tests that amount to:
int var1 = some_default_value;
int var2 = some_default_value;
assertEquals(var1, var2);
Glad we use up valuable CI resources for these tests.
One of my teammates is guilty of this and it annoys me to no end. Their PRs are AI-generated from the main code to tests to PR description and when they get comments, they replies are also AI...
One of my teammates is guilty of this and it annoys me to no end. Their PRs are AI-generated from the main code to tests to PR description and when they get comments, they replies are also AI generated.
The tests I'm seeing it write for my projects aren't all that rigorous but I haven't seen it write complete crap either. I think it's okay but you have to keep an eye on it. Back when I was...
The tests I'm seeing it write for my projects aren't all that rigorous but I haven't seen it write complete crap either. I think it's okay but you have to keep an eye on it.
Back when I was working I would see tests that don't actually do anything written by people, too. Usually due to heavy use of mocks.
Ah yeah I wasn't clear on that but yes, an extensive HUMAN WRITTEN test suite was why this was "easy". AI works well in the cases where the known output is already confirmed and testable. If you...
Ah yeah I wasn't clear on that but yes, an extensive HUMAN WRITTEN test suite was why this was "easy". AI works well in the cases where the known output is already confirmed and testable. If you said "build an app like bun in rust and make tests" you'll get a disaster.
Not just Claude, but most likely Claude Mythos. Bun was bought by anthropic because it's used for Claude code, so they almost certainly have free access to Mythos.
Not just Claude, but most likely Claude Mythos. Bun was bought by anthropic because it's used for Claude code, so they almost certainly have free access to Mythos.
Effectively Bun is now 'open source' in name only since no sane human being will review or work on a million lines of AI generated code. The whole project can now only be worked on with LLMs. In...
Effectively Bun is now 'open source' in name only since no sane human being will review or work on a million lines of AI generated code. The whole project can now only be worked on with LLMs.
In some sense it's the open source version of "Flood the zone with shit".
I think it's hard to say at this point how this will pan out. Here's the current output of cloc on the repo: ---------------------------------------------------------------------------------------...
I think it's hard to say at this point how this will pan out. Here's the current output of cloc on the repo:
The AI-written rust has way more comments (not surprising, AI loves to write comments). I could see the increase in LoC from the zig and rust versions as due to inherent verboseness of rust code. You're tracking more things using language features, so you need a few more LoC to do the same work.
The most worrying number is the increased file count. Rust has 11% more files than zig. I suppose that means (very hand-wavey) it's 11% more complicated in architecture see below.
Edit: So says my LLM, the extra LoC mostly come from rust RAII and trait boilerplate. The code seems to be a pretty clean 1:1 port so I expect people familiar with the original code architecture could easily get up to speed with the new code.
Edit 2: The extra rust files are mainly lib.rs, mod.rs and build.rs files. The rust code also puts FFI boilerplate into separate files while zig does not.
Thanks for the info! I just think if I had worked diligently on efficient Zig code for this project as a contributor before, I'd feel completely deflated after this move. Jarred Sumner allegedly...
Thanks for the info!
I just think if I had worked diligently on efficient Zig code for this project as a contributor before, I'd feel completely deflated after this move. Jarred Sumner allegedly llm'd all this in a few days, and if I had been a (non-AI) contributor to this project, I'd be absolutely demotivated to work on this now.
Also this can't be good Rust code, right? A 1:1 port from Zig has to have thousands of unsafe sections, circumventing the borrow checker and Rusts philosophy. I can't imagine that Rust devs would want to work on a project like this.
But yeah, it's going to be interesting to see how it pans out.
Supposedly the port has already fixed a few memory safety bugs. Look for yourself if you want to see how the code looks. If you were a contributor I think you’d find your old code in there just...
Supposedly the port has already fixed a few memory safety bugs. Look for yourself if you want to see how the code looks. If you were a contributor I think you’d find your old code in there just with a different coat of paint.
It doesn't load on my end - but like, what's the point of this rewrite? Is Bun so slow that Rust was needed here? Did it provide a measurable performance improvement? I had the impression that Bun...
It doesn't load on my end - but like, what's the point of this rewrite?
Is Bun so slow that Rust was needed here? Did it provide a measurable performance improvement? I had the impression that Bun is the faster of the JS tools.
I am genuinely in love with Rust, so the more big projects in it the better, but I'm also a practical person, and rewrites are not always the best idea, unless the architecture was flawed or the stack was just so awful.
Memory safety. Rust has stronger rules for this, and the lead dev straight up cited tons of time dealing with segfaults as the reason for the jump. There are other arguments that it's because...
It doesn't load on my end - but like, what's the point of this rewrite?
Memory safety. Rust has stronger rules for this, and the lead dev straight up cited tons of time dealing with segfaults as the reason for the jump.
There are other arguments that it's because since anthropic acquired bun and Zig is heavily anti AI anything in their code base that this was another reason because they couldn't contribute to Zig development, but i haven't looked into that side so grain of salt. I have no idea how much of that is true or not.
Edit:
Last comment I read from them on HN:
Still writing the blog post about this. Will share more details.
For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors or automatic cleanup.
Ah, okay, in retrospect that makes sense for a JS runtime. If Zig & C++ cause that much trouble for them then it's a worthwhile effort. That said I do believe they could have done an incremental...
Ah, okay, in retrospect that makes sense for a JS runtime. If Zig & C++ cause that much trouble for them then it's a worthwhile effort.
That said I do believe they could have done an incremental rewrite instead of just converting it all at once, but if the test suite is as robust as they claim (haven't checked it myself) then maybe it is fine, alongside a proper beta test phase.
The original take was “fuck it why not” with the expectation they’d probably throw it out. It apparently performed better than they expected hence the full rewrite
The original take was “fuck it why not” with the expectation they’d probably throw it out.
It apparently performed better than they expected hence the full rewrite
Man what a waste of electricity. Now there's a PR filled with so much crap nobody can review it, which means bugs will absolutely be introduced. For what?
They're doing the rewrite because they frequently have bugs caused by memory safety issues, which Zig, like C and C++, does not have good protections against. It's true that this rewrite has a lot more usages of unsafe blocks than most Rust projects, but it's a huge improvement from all the code effectively being inside an unsafe block as before, they're manually cutting down on many unnecessary unsafe blocks, and any new code that's written as idiomatic Rust from the start should be free of new memory safety issues.
They're swapping memory bugs for slop bugs.
It's a file-for-file conversion. The new codebase will be very similar in structure and control flow to the old codebase. It's likely not very idiomatic Rust, but it's not as if they vibe coded a million lines without any review. It should be familiar for any existing contributors.
They also have a very clear picture now of where the
unsafekeyword is used, and can target those areas for improvement. Rust offers a lot of assurances that Zig did not. There's likely some edge cases still to shake out, but I expect it's no buggier than the code that came before.In theory, yes, but the small amount of a couple of files that I've seen, I think the new codebase would need a lot of care and attention to be useable by human contributors. There are lots of weird things like the LLM inlining imported functions from other files, resulting in duplicated, subtly different functions lying all over the place; or the LLM writing functions that made sense in Zig but don't make sense in Rust. The result feels fairly chaotic, I don't think any developer is going to be familiar with the new codebase.
I also am unsure about the unsafe keyword issue. One of the dangers of improper use of
unsafeis that it can do spooky action at a distance - code that is marked as unsafe may run fine, but it may result in data that violates an invariant somewhere else. So now seemingly safe code is implicitly unsafe. If you're careful, you can build data structures that enforce the right invariants, meaning that the unsafe logic is confined to a certain spot. But it doesn't seem like the Bun uses of unsafe do that. I suspect untangling this amount of unsafe is going to be a very difficult challenge.There's also the issue that LLMs might but be as good at rewriting or porting as they appear at first glance. A while back, someone wrote a Python HTML5 parser, and other people vibe-ported it to other languages. Except the ports did weird things - they all had subtly different algorithms for some of the internal parts, even though they had all ostensibly come from the same code suggesting the LLM basically wrote its own version of some of the code, rather than doing a straight port. These sorts of subtle issues are difficult to notice at the sort of scale of this PR.
The final issue is that the code the came before was very buggy - that's supposedly why they made the change. And in theory that makes sense - before there were a bunch of memory safety issues, Rust solves (insert asterisk here) memory safety, so switching to Rust should help a lot. But other Zig projects have not been struggling as much as Bun has with memory safety, so I don't think it's so simple to say that Bun's previous issues were because Zig is too lax, and Rust will solve them. Rather, I suspect Bun's previous issues have not to do with issues with how Bun is being developed, and that switching to Rust won't resolve those underlying issues at all. Instead, you're just going to end up with different categories of bug that Rust doesn't do anything to prevent.
All valid points. Notably I'll agree that I have seen LLMs reimplement something without additional prompting, just as a matter of course. Strong enough tests would help mitigate that, as the behavior should at least match, but it's unlikely to account for all scenarios.
I think these devs are looking at a lot of work no matter what. A ground-up rewrite would have likely taken years of dev hours to get to the same point that Zig-Bun was at, but a full conversion will still require months-to-years of review to check everything for correctness.
The third option - to continue on with Zig likely wasn't ideal either. I don't know if they're overstating the memory issues to justify the port, but I imagine there's other difficulties of using off brand languages that they've run into.
I suspect, considering the current paradigm shift in software engineering right now, that the economics of these decisions may be rapidly changing. It may be less about the scope of the work, and more about the capability of the models themselves. Are they better at writing code, reviewing it for correctness, reshaping it for idiomatic style, or discovering memory bugs?
It's an interesting experiment, if nothing else. I expect a lot of large tech companies are considering a similar project. Memory issues are still the number one killer, and I can imagine a lot of engineers salivating at the idea of a 100% Rust codebase. Maybe we'll see Google Chromium or even the Linux kernel making the same move in a couple of years.
I'm not sure the economics are changing so much.
Firstly, LLMs are getting more expensive as the major providers stop subsidising their usage (see Anthropic's recent terms of use changes, and GitHub's big price increases). Bun could do this because they're owned by Anthropic and basically have access to unlimited Claude usage for free (and possibly even the new Mythic model?).
Secondly, most big projects in memory-unsafe languages don't suffer from bugs to the extreme extent that Bun has. Yes, there's good reason to push for more usage of memory safe languages in critical parts of core software like browsers or the kernel, but there are also a bunch of other tools that can at least partly mitigate issues. But Bun has always been buggy beyond just that. And maybe it's because Bun has unique challenges that make it harder to get memory safety right than in, say, Tigerbeetle or Ghostty or whatever else is using Zig, but I don't think most other projects are going to get as much value out of a rewrite.
And thirdly, the proof is going to be in the pudding. It's not enough to spend vast numbers of token generating a new version of Bun - they also need to prove that the new version is materially less buggy. They've not really done that yet. In fairness, this is just an initial port, and there's a lot that needs to be cleaned up from this point in, but like I said before, I don't think Bun is buggy because of memory safety, I think it's buggy because it's not very good. So I suspect we're just going to see memory safety issues and segfaults going down, but there's just going to be other bugs instead that make up the balance. That is, for an end-user of Bun, I don't think there's going to be much difference.
Just want to push back on this a bit. It is true that token costs from the large providers typically increase with new models, the cost per "intelligence" has been going down. This is most obvious from OpenAI, where GPT 5.5 is cheaper than 5.4. If you need intelligence equivalent to 5.4 xhigh, 5.5 medium gets you the same result with lower token usage and lower costs. Anthropic is less of a clear win, but Opus 4.7 is both more intelligent and cheaper than 4.6. If you include the fact that Chinese open weight models are typically right behind western models and significantly cheaper to run, the cost future looks even more promising. If you stabilizes your needs on a set "intelligence" level, your costs will go down over time.
I mean more in the sense that a lot of companies right now seem to be relying on subsidised inference - see Claude's subscriptions where loopholes are being slowly tightened, or GitHub Copilot's subscriptions which has recently become significantly more expensive. I think in the long term you're right, but I think in the short and medium terms, companies are typically going to end up paying more than they are currently, at least for developer tasks like this one.
Those graphs are based on API pricing which has not changed or increased. Companies use API pricing, not subscriptions. Chatgpt itself doesn't even have the 100 and 200/month plans for business.
The companies I've been working with have basically all used either GitHub Copilot or Claude. API pricing has mostly just been used for the occasional integration (i.e. when building a tool that has AI integration, use API pricing for that integration, but for the actual programming of it use Copilot/Claude subscriptions).
In fairness, these have mostly been smaller companies (<100 developers) and I can imagine things are different for bigger corporations.
That's true. Chrome has MiraclePtr, for instance, and some very extensive fuzzing suites. They also have the Rule of 2 to avoid the most common pitfalls. But it's a careful balancing act, and likely introduces a lot of friction compared to just writing code in a memory-safe language to begin with.
On the topic of economics, I'm not sure what to think. It does seem that even the SotA models only have a few months lead. Deepseek, Kimi, GML and others are right behind Claude and OpenAI. And with the ongoing advances that make this tech more accessible to local hardware, I think it's more likely than not that it will be commoditized at some point.
I agree that Bun likely had a number of issues besides memory safety, and this change won't have any effect on those. I will be curious to see how things shake out in the coming months, though. It could be a big mistake. It could be a sign of things to come.
You make some good points. Definitely using Rust was a good call. But I have to add, it will definitely be buggier, less idiomatic, less elegant and more bloated than before. That's just where LLM coding agent technology is right now. It's not as if being under the Anthropic umbrella gives them magical powers to make agents perform better. Look at how buggy, verbose and convoluted Claude Code is. It would be different if it was human led with AI assistance rather than just letting the agents churn... but it doesn't sound like that's how they did it given the short timeframe.
Caveat: if they used Mythos and it's lightyears ahead of Opus, maybe it's better than I'm imagining. I'd say that's somewhat unlikely.
Whatever the case, Claude Code and Codex, despite their issues, have proven that you can ship messy, vibe coded software and people will use it. Vibecoded doesn't mean the new Bun won't be successful.
I expect they probably are using the best model available under Anthropic, whether that's Mythos or some variant. But even then, it can't be better than a 5-10% improvement over publicly-available models. I doubt there's any real magic sauce there.
However, I still feel there's a large difference between converting existing software to a new language, and writing software from scratch. Starting a new project requires a lot of design decisions upfront such as overall infrastructure and scope, where to apply abstractions, and what assumptions can be made. Somebody prompting "make me an X" isn't addressing any of those considerations.
A project built in Rust will likely have different considerations from a project in Zig, but they're not so wildly different as to be incomparable. If it makes sense to abstract a function in Zig, it probably makes sense to do it in Rust. Some of the specific language writing will probably feel "weird" and non-idiomatic, but not broken. Refactors can help address those areas in the future.
I'll mention that transformers were originally designed specifically for language translation, for applications like Google Translate. They manage very well at that task, and that's with all the messy complexities of human language. Programming languages are considerably more logical and well-defined, which makes them even better candidates for language translation/conversion tasks.
So this may be vibe coded in the strictest sense of the term, but I'd guess the quality is still reasonably high. Something like Claude Code is a rather different beast. It's been hacked on by many individuals, and has gone through constant changes in scope and direction. That can be the real quality killer.
edit: Typo
The thing about tests... When the model hits a failed test, or a parse error, or otherwise unexpected behavior, it starts making decisions, and if you've ever used a coding agent on anything non-boilerplate you know exactly what those decisions look like.
A lot of times they're ok, sometimes they're great, but sometimes they're incredibly bad. An extensive test suite and the code in another language can reduce that problem but not eliminate it. When you have as much code as they just vibed... I really don't envy the maintainers. There's going to be a strong incentive to slam the hood back down and have agents do the work going forward. Plus they're in Anthropic's world, everything is vibecoded, so there's a cultural incentive too. It may not be Claude Code yet, but it's already on the path.
Note that I'm not making any predictions, a year ago I wouldn't have bet on Claude Code being anywhere close to maintainble at this point and it's still going strong. It ain't pretty, but millions of people use it every day anyway.
So, when Bun was created, they very loudly chose for Zig over Rust, because it gave them the memory control they needed for their very high performance standard. And fair enough: this is one of the main selling points of Zig and something Rust is explicitly not designed for (not as a main goal anyway).
And now, they come out with a fully generated AI PR, completely unreviewable code, probably also AI slop, saying: yeah, we didn't need that control after all, Rust is actually better because it gives more memory safety.
This was clear from the start, why did you suddenly change now? Was it because Zig was the language of the day at the time? The whole thing just makes me doubt about their initial reasoning, their ability to use AI responsibly and also makes me worried about Astral/UV and OpenAI.
It's pretty clear that they abandoned Zig because of the Zig project's scepticism about vibe coded slop. This whole saga started when they submitted a giant AI-coded PR to Zig, which got rejected for a variety of reasons - all of which seemed pretty reasonable to me. Someone clearly got annoyed by that and decided to try to cut ties.
What happens outside the zig compiler project does not matter whatsoever.
I don't recall it being all that big (maybe we're thinking of different PRs.) I do remember looking at it, and — whether AI or not — it just didn't seem to align with the core team's direction / approach to improving compiler performance.
I think that tweet was posted in bad faith, I don't think it would have been merged to begin with.
Interesting theory, hadn'r linked those two events together. I don't think they'll have an easier time making similar PRs to the Rust project though.
Can’t they just have been wrong about zig? I always thought zig was a stupid choice.
Maybe, yes. I agree with that Rust probably would've been better for this particular usecase, from what I can see at least. I don't know if it was stupid though, there are certainly legitimate reasons to use Zig and some projects use it with great success.
Wow that’s a huge PR! GitHub comments (just GitHub in general I guess) are really struggling to load right now, but judging from the tags here it seems the rewrite is heavily AI-assisted? Perhaps entirely done by AI agents?
Not assisted, done entirely by Anthropic's Claude.
This is not wrong, but I do want to be clear that a huge reason this was so successful is because of a very well written and detailed test suite. AI works wonderfully when it can determine its wrong, and it can't flub the test.
Notably:
Don’t let Claude write the tests itself. It likes to pretend to write tests but then just build trivial tests
It's fun going through my company's codebase and seeing tests that amount to:
Glad we use up valuable CI resources for these tests.
Some people turn on the AI and turn off their brain.
One of my teammates is guilty of this and it annoys me to no end. Their PRs are AI-generated from the main code to tests to PR description and when they get comments, they replies are also AI generated.
Sounds like they’ve quit
Funnily enough they actually joined the company same day I did just a few months ago so I wonder if they're already looking for their next move.
The tests I'm seeing it write for my projects aren't all that rigorous but I haven't seen it write complete crap either. I think it's okay but you have to keep an eye on it.
Back when I was working I would see tests that don't actually do anything written by people, too. Usually due to heavy use of mocks.
Ah yeah I wasn't clear on that but yes, an extensive HUMAN WRITTEN test suite was why this was "easy". AI works well in the cases where the known output is already confirmed and testable. If you said "build an app like bun in rust and make tests" you'll get a disaster.
Not just Claude, but most likely Claude Mythos. Bun was bought by anthropic because it's used for Claude code, so they almost certainly have free access to Mythos.
Effectively Bun is now 'open source' in name only since no sane human being will review or work on a million lines of AI generated code. The whole project can now only be worked on with LLMs.
In some sense it's the open source version of "Flood the zone with shit".
I think it's hard to say at this point how this will pan out. Here's the current output of
clocon the repo:The AI-written rust has way more comments (not surprising, AI loves to write comments). I could see the increase in LoC from the zig and rust versions as due to inherent verboseness of rust code. You're tracking more things using language features, so you need a few more LoC to do the same work.
The most worrying number is the increased file count. Rust has 11% more files than zig. I suppose that means (very hand-wavey)
it's 11% more complicated in architecturesee below.Edit: So says my LLM, the extra LoC mostly come from rust RAII and trait boilerplate. The code seems to be a pretty clean 1:1 port so I expect people familiar with the original code architecture could easily get up to speed with the new code.
Edit 2: The extra rust files are mainly
lib.rs,mod.rsandbuild.rsfiles. The rust code also puts FFI boilerplate into separate files while zig does not.Thanks for the info!
I just think if I had worked diligently on efficient Zig code for this project as a contributor before, I'd feel completely deflated after this move. Jarred Sumner allegedly llm'd all this in a few days, and if I had been a (non-AI) contributor to this project, I'd be absolutely demotivated to work on this now.
Also this can't be good Rust code, right? A 1:1 port from Zig has to have thousands of unsafe sections, circumventing the borrow checker and Rusts philosophy. I can't imagine that Rust devs would want to work on a project like this.
But yeah, it's going to be interesting to see how it pans out.
Update: Claims of memory safety issues and general slop
That entire thread is weirdly both hilarious and terrifying.
Supposedly the port has already fixed a few memory safety bugs. Look for yourself if you want to see how the code looks. If you were a contributor I think you’d find your old code in there just with a different coat of paint.
It doesn't load on my end - but like, what's the point of this rewrite?
Is Bun so slow that Rust was needed here? Did it provide a measurable performance improvement? I had the impression that Bun is the faster of the JS tools.
I am genuinely in love with Rust, so the more big projects in it the better, but I'm also a practical person, and rewrites are not always the best idea, unless the architecture was flawed or the stack was just so awful.
Memory safety. Rust has stronger rules for this, and the lead dev straight up cited tons of time dealing with segfaults as the reason for the jump.
There are other arguments that it's because since anthropic acquired bun and Zig is heavily anti AI anything in their code base that this was another reason because they couldn't contribute to Zig development, but i haven't looked into that side so grain of salt. I have no idea how much of that is true or not.
Edit:
Last comment I read from them on HN:
Ah, okay, in retrospect that makes sense for a JS runtime. If Zig & C++ cause that much trouble for them then it's a worthwhile effort.
That said I do believe they could have done an incremental rewrite instead of just converting it all at once, but if the test suite is as robust as they claim (haven't checked it myself) then maybe it is fine, alongside a proper beta test phase.
The original take was “fuck it why not” with the expectation they’d probably throw it out.
It apparently performed better than they expected hence the full rewrite