Rewrite Bun in Rust has been merged

Rewrite Bun in Rust has been merged(github.com)

696 points by Chaoses 4 days ago | 783 comments

sesm 3 days ago |

When announcements say that rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...

On top of that, if you look at 'Pointers & ownership' and 'Collections' sections, the Bun codebase is already prepared, using internal smart pointer types that map 1-to-1 to Rust equivalents, and `bun_collections` Rust crate already exists.

This makes an impression, that rewrite was prepared long time ago and was Bun team proposition to Anthropic during the acquisition deal.

jaccola 3 days ago | |

Yeah I don’t know what’s true when reading about LLMs. Same with comments here on hacker news. So much money on the line it’s clear they would seed communities with marketing shills (and some people are just tribal).

Same since they own Bun, they have every incentive to make this seem easier than it was.

torben-friis 3 days ago | | |

This is a huge problem regarding the specifics of ai. Tech is becoming very adversarial as a worker, since marketing and technical information are blurring lines more and more.

cortesoft 3 days ago | | |

You can just use AI for yourself and see. It isn't some mysterious product that only a few people get to use.

fny 3 days ago | | |

I'm not sure it matters what anyone claims. It's easy to use and experience its abilities and limitations.

port11 3 days ago | | |

The truth lies somewhere in the middle.

Context: 20 years coding, 13-ish of which professional. Using LLMs for side projects, including a very big one. Also using them to help manage our home server.

I’ve used 20-ish agents with OpenRouter, Google’s own AGY, Mistral’s Vibe, and Claude Code. The good ones are good and can be very helpful with spec’ing work or handling repetitive tasks. Except for Opus 4.6, none of them produce TypeScript that I’d be super proud of; but they write stuff that’s good enough compared to what I’ve seen in the industry. It’s always some mix of spaghetti and shortcuts. That’s fine, you steer the model and tighten your specs and tests.

Anyone claiming ‘Model X can one-shot’ an app is delusional about maintainability, deployment, all the little things that grease the wheels. Anyone claiming ‘LLMs are useless’ is probably not being impartial. That’s it.

And any company claiming AI is awesome at everything and will replace everyone? Yeah, they’re lying, at least about their capabilities as of right now.

sunrunner 3 days ago | |

Ignoring things like whether the Rust that was output could be deemed qualitatively good, whether the resulting line count is appropriate, how much the codebase was ready or primed for this kind of exercise going in, and so on, is it fair to say that a 622 line artefact created up front is a relatively small cost for a potential increase in consistency or quality of output when the output is ~1M LoC? It seems like there's a multiplicative power here given how much output there is. Or is that missing a lot of nuance?

I'd also be interested generally in how much tacit knowledge was needed to come up with these rules and how much iteration on this file was needed, for example how many of the rules here came from a failure case hit as part of iterating on the translation.

xienze 3 days ago | | |

> I'd also be interested generally in how much tacit knowledge was needed to come up with these rules and how much iteration on this file was needed, for example how many of the rules here came from a failure case hit as part of iterating on the translation.

I think that's the point the original poster was making. There's basically zero chance this file was just spit out by memory in an afternoon. It was obviously the result of a LOT of pre-planning and back and forth checking over the artifacts that Claude was incorrectly generating for one reason or another. So yeah, an extremely iterative process.

With rules as fine-grained as these, there was almost certainly many instances where hundreds of files are generated -> one particular file doesn't translate <X> correctly -> add a rule for <X> -> regenerate everything again -> crap, that rule broke a different file because <Y> -> add a rule for <X if Y>, another for <X not Y> -> regenerate everything again[0] -> repeat. The token costs must have been out of this world.

0: now I'm sure people will say "why would you regenerate a file that generated correctly once? Just mark it off the list and move on." Well, when essentially 99.9999% of your codebase is generated artifacts, the tiny fraction that is actually human-understandable is now the spec, the source of truth for everything. It HAS to be able to essentially redo the entire process if you expect any level of maintainability going forward.

fdsajfkldsfklds 3 days ago | | |

This is effectively a very expensive and resource-intensive machine translation. As such, there is no increase in consistency or quality of output.

cyanydeez 3 days ago | | |

I would guess it was a for ... each loop. They likely wrote a bunch of skills. The foor loop went through each file and generated a complimentary file, then had another process integrate/validate.

I doubt the entire process was a single week, just whatever harness they specially prepared for the work.

ryukoposting 3 days ago | |

Similar highly crafted success stories getting passed around within some big tech firms right now.

We got told that someone wrote a huge, sophisticated driver in Rust in a single day using Claude Code. This is being pushed as a case of AI doing something that we encounter on a regular basis, way faster than a human could do it.

Some ommitted details: Turns out the official spec for this driver is written in C, and the standard has a massive official suite of unit tests.

ares623 3 days ago | |

It's the same thing with their gcc stunt.

It would be _so_ easy to alleviate any doubt from this and hype up the IPO even more. They just need start a separate repo with all the hidden work they needed to do to prod the AI along, and let everyone replicate the results. After all, isn't that what all their customers are trying to achieve? A million lines of usable code in "7" days? Never mind the fact that it will also boost Anthropic's usage metrics as everyone tries to replicate it into their workflows.

If it was beautiful, they would've started with a blog post about this with links and instructions. Perhaps I will still be proven wrong and a blog post is being written as I type this.

SwellJoe 3 days ago | | |

Which part of a Zig to Rust port (working, passing tests) of a quite large codebase in a little over a week is not worthy of hype do you reckon? That they didn't one-shot it? What could possibly make it impressive if not the sheer velocity of the thing? That's a months or years long operation for a human. There's a reason porting large programs to new languages was vanishingly rare throughout most of computing history, and there's a reason people are suddenly doing it almost on a whim, now.

Aurornis 3 days ago | |

> using internal smart pointer types that map 1-to-1 to Rust equivalents

Smart pointers weren't invented by Rust. If you write code in other languages with pointers you mentally model the same types already.

> and `bun_collections` Rust crate already exists.

This is wrong. It's part of the PR in the codebase. It did not previously exist.

sesm 2 days ago | | |

Agree, after closer look smart pointer types are pretty standard and collections were indeed a part of migration.

But still, in order to prepare those detailed and very project-specific instructions you need to iterate on trying to convert the files from this specific codebase.

gofreddygo 3 days ago | |

Its like that hackathon winner project that everyone knows wasn't ideated or built there. True to the law, not to the spirit.

illiac786 3 days ago | |

Yes, there is exaggeration going on.

Nonetheless, it’s a fact it would have taken much longer without LLMs, I’d say all possible.

I find this is a valid success story if you can look past the embellishments. More than that, it’s really cool, actually.

exac 3 days ago | |

Based on the use of "≥" and em-dashes, I'd say this markdown file was written with or by an LLM.

bmitc 3 days ago | |

That makes the Bun owner's claim, just a week ago in this site, even more dubious when he came on here and said this code was just an experiment and likely to be thrown away.

user34283 3 days ago | | |

I don't think the owner lied, but rather that the entirely speculative comment on here is obviously wrong.

It says here in the comments that it's mistaken about the supposed previous existence of the crate.

tln 3 days ago | |

Seems like Zig Bun had 3 pointer types that map neatly to existing Rust pointer types. The other 7-8 needed types to be created.

Is that the conspiracy?

bun_collections doesn't look much older than the porting guide.

thayne 3 days ago | |

Given zig instability (as in frequent breaking changes), it wouldn't surprise me if they intentionally design bun from the start in a way to make it easier to migrate to rust if needed.

Jarred 3 days ago |

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.

gm678 3 days ago |

    $ rg 'unsafe [{]' src/ | wc -l
    10428
    $ rg 'unsafe [{]' src/ -l | wc -l
    736
    
    Language        Files     Lines      Code  Comments    Blanks
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    Rust             1443    929213    732281    116293     80639
    Zig              1298    711112    574563     59118     77431
    TypeScript       2604    654684    510464     82254     61966
    JavaScript       4370    364928    293211     36108     35609
    C                 111    305123    205875     79077     20171
    C++               586    262475    217111     19004     26360
    C Header          779    100979     57715     29459     13805

vitaminCPP 3 days ago |

> +1009257 -4024

Bun is now over 1M lines of Rust code.

This is approaching the size of the Rust compiler itself; except that BunJs is mostly a JavaScript interpreter wrapper + a reimplementation of the NodeJS library (Rust STD wrapper).

I think BunJS is becoming the canary for software complexity management in the LLM era.

xiphias2 3 days ago |

I'm actually excited for somebody trying experimenting with automated translation, but I'm afraid this will be lots of backwards compatibility issues.

I started looking at the commits, and it's basically solving the ,,tests not pass'' problem by changing the tests themselves. The real work of making it working on programs that are already deployed will be just starting now.

The only silver lining I see is that the server side JS community for some reason is already used to breakages all the time.

weraK10 3 days ago |

As an educational thread, see this one from a week ago where Jarred again deflects from a merge decision and legions of foot soldiers attack anyone who predicted the impending merge:

https://news.ycombinator.com/item?id=48073680

Didn't age well, did it?

progforlyfe 3 days ago | |

From "This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely." and what seems to amount to some experimental curiosity -- to merging the whole thing in 10 days!? This seems really crazy.

rcxdude 2 days ago | |

I think framing such discussions as a war is not really going to result in a good discussion.

wiseowise 3 days ago | |

It'll never cease to amaze me how many bootlickers are out of there that don't really care which boot to lick.

rcxdude 2 days ago | | |

Arguing against a particular criticism of something doesn't mean you entirely agree with that thing, or that you are subservient to it at all.

therepanic 3 days ago |

About 9 days ago, Jarred wrote that it was far from certain that this would merge and that it was an overreaction. Ironic.

wiseowise 3 days ago | |

Model open source leadership. Imagine the meltdown if Linus says Linux kernel is not going to be rewritten and then one day wakes up and merges full machine-assisted rewrite in Rust.

pessimizer 3 days ago | | |

As long as it was still GPL and it wasn't just license washing, I'd be elated.

noosphr 3 days ago | |

When you don't own your company any more anything you say can be safely ignored. It was obvious that the token spend will need to be justified.

simlevesque 3 days ago | | |

They've been shady since day one, claiming wild performance improvement compared to their competitors and never proving any of them.

rcxdude 3 days ago | |

I mean, that doesn't exclude the outcome that it gets merged.

manlymuppet 3 days ago | |

That doesn't mean he was lying. Just that things changed.

It was uncertain then, and not so uncertain now.

noodletheworld 3 days ago | | |

> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.

I would say it is reasonably clear they had already committed to rewriting at that point.

The possibility that that particular code might be thrown out was potentially true, but also totally unrelated to the previous statement.

At the end of the day, whatever, but this feels a heck of a lot like “ah, we didn't mean for this to be public yet” rather than “this is just a random experiment”.

AI companies love AI stories.

It is an AI company.

[1] - https://news.ycombinator.com/item?id=48016880

sltr 3 days ago |

I will move the handful of my projects that use Bun to something else. I don't trust governance that permits this kind of reckless change.

steve_adams_86 3 days ago | |

Deno is amazing and doesn't get the love it deserves, in my opinion.

It doesn't need to be rewritten because it was written well in the first place.

4b11b4 3 days ago | |

Same, just gonna stick with node. On the other hand, the trial by fire will be interesting to see... long term I can only imagine the kinks will surely work themselves out

szmarczak 3 days ago | | |

Wait till you hear about https://github.com/nodejs/node/pull/61478

ksec 2 days ago | |

I am wondering if anyone is going to fork Bun because of this.

asciimoo 3 days ago |

Regardless the outcome, this is such a disrespectful move towards the huge amount of contributors who invested time and effort to learn the project and make it better. I hope the zig/dev community forks the project and continues the development. I'd rather use the fork than this project that has sacrificed its contributors for marketing purposes.

embedding-shape 3 days ago | |

> this is such a disrespectful move towards the huge amount of contributors who invested time and effort to learn the project and make it better.

What? How?

You contribute to projects run by others with the understanding that others run the project, is this not the default assumption others have too when contributing to FOSS?

Is it disrespectful if my proposed feature was merged, but then later was removed because the maintainer just didn't want the feature anymore? In my mind, pretty clear it wouldn't, I'm only a contributor after all, not the maintainer or the person running the project.

asciimoo 3 days ago | | |

> Is it disrespectful if my proposed feature was merged, but then later was removed because the maintainer just didn't want the feature anymore?

No, the big difference is that the described scenario does not require getting familiar with a new 1M LoC codebase written in a different language to be able to continue contributing to the project.

jd3 2 days ago | | |

> You contribute to projects run by others with the understanding that others run the project, is this not the default assumption others have too when contributing to FOSS?

There are certain unspoken rules you don't break out of a of tradition of process and decorum — this decision broke that rule, overturning 5+ years of accrued experience and institutional memory, so I can understand why this might feel like a rugpull which would reasonably upset the average contributor.

These antics are acceptable in a BDFL project where the stakes are low, but try this in an actual major project with thousands of contributors and see how it goes.

I think the best case scenario I can think of is the microsoft typescript js->go conversion, whereas the bun zig->rust is probably the worst case.

tasn 3 days ago | |

How is that different (in this sense) to any "slower" rewrites or other significant changes?

asciimoo 3 days ago | | |

The difference is exactly the speed. Slowly transitioning from one thing to another gives the opportunity to contributors to get involved in the process.

losvedir 3 days ago |

Wow. This is going to be interesting to follow. There's absolutely no way any of this code was reviewed, but maybe we're in a post-human world now where you can trust the models to write and review the code. This is like Gastown but on a higher profile project. Will be fascinating to see how this project is able to add new features going forward (or even _if_ it will be able to).

Does anyone know how exactly Bun is used by Anthropic? Is it a part of Claude Code? I'm more than slightly worried about using Bun going forward myself, but I'm not sure to what extent that applies to using Claude as well.

sensanaty 3 days ago |

Love seeing the tests themselves getting modified, with random `sleep(1)` thrown around in a few of them. This bodes well, I pray some idiot at some large AI co actually ends up using this garbage in prod

dolmen 3 days ago | |

Claude Code uses Bun as its runtime.

If this has been merged, I expect that Bun-rust is good enough to power Anthropic's internal agents to do live testing.

merlindru 3 days ago | | |

Jarred had tweeted that they're using the rust version internally with Claude Code

eqvinox 3 days ago |

If this goes wrong even in the slightest, the ridicule about a drug dealer getting high on their own supply will be neverending and grim.

perching_aix 3 days ago |

PR so thick, the page failed to load the first time I opened it, and the comments still continue to fail to load. Absolutely hilarious. Though that may be just GitHub having a normal one, hard to tell these days.

1 009 257 lines added

4024 lines removed

6755 commits

2188 files touched

I haven't the slightest clue how anyone would even remotely hope to review this. I guess by just using even more AI? Or maybe by throwing some über hardcore lint pass onto it? It really seems like more an exercise in risk assessment than code review.

12_throw_away 3 days ago | |

The maddening thing is that there's a right way to do this if you have the patience and professionalism to do so. It requires building a bit of scaffolding (feature flags, cross-language calling support, harnesses for shadow testing, etc.), then you ship-of-theseus the codebase incrementally. This is not even incompatible with LLM-assistance, plus it breaks the thing up into smaller, reviewable changes that don't break your diff tool!

However, doing it the right way takes a bit more time, involves community feedback, and doesn't produce headlines about huge codebases being rewritten by LLMs in just a few days, so ...

hombre_fatal 3 days ago | | |

There is never a right way, only trade offs.

The thing about being a Monday morning quarterback is that you can always claim you would have used even more caution and process.

kccqzy 3 days ago | | |

Ah yes, you are actually describing fish shell's Rust rewrite. They specifically called it The Fish Of Theseus which is of course a reference to the ship of Theseus.

https://fishshell.com/blog/rustport/

chamomeal 3 days ago | | |

I mean it's definitely at least partially a PR stunt

12345hn6789 3 days ago | |

Humans are no longer maintaining bun. There is no good faith argument that can claim a human understands this rewrite

chrysoprace 3 days ago | |

Not sure there is much of a point in reviewing a port of this size. It has >1000 instances of `unsafe` and uses the same patterns as the zig code according to Jarred. It feels like a vibe-ported version of what the TypeScript team are doing porting from TypeScript > Go with codemods.

fg137 3 days ago | |

Bun is owned by Anthropic.

Hopefully that answers all your questions.

azangru 2 days ago |

Remember the top comment to this Hacker News thread? https://news.ycombinator.com/item?id=48016880 "This is an overreaction." "302 comments about code that does not work." "We haven’t committed to rewriting." "There’s a very high chance all this code gets thrown out completely."

Well. That was about a week ago.

wesselbindt 3 days ago |

This kind of frivolous nonsense disqualifies bun from ever being a serious option to me. I'm not building any kind of software used in a professional setting on 1M lines of unreviewed code.

nicce 3 days ago | |

Odd take. Bun was not option for me because or Zig. There was no security. Issue tracker has 3000 issues about segfaults. Now I might actually reconsider.

steve_adams_86 3 days ago | | |

> There was no security

>1M lines of un-reviewed code are secure?

wesselbindt 3 days ago | | |

I don't believe you actually think it's odd to not want to run unreviewed code in prod. I accept that you might disagree, but I don't believe this is a take you haven't heard a million times before.

vermilingua 3 days ago |

Having just migrated all my teams repos to Bun, I feel… stupid. I was already feeling a little nervous by the time of the acquisition but this is pretty rough.

simonklee 3 days ago |

Say what you want, but for people building products on Bun, this is bad news for the foreseeable future.

arealaccount 3 days ago | |

I guess it’s time to have Claude rewrite my Bun app in Deno

sesm 3 days ago | | |

I'm sorry, Dave. I'm afraid I can't do that.

KronisLV 3 days ago | | |

Hear me out, what if we rewrote Deno in Zig?

bflesch 3 days ago | | |

That's a great idea! Once you've granted access to your private repository I can do that.

avithedev 3 days ago | | |

This made me laugh loud

TiredOfLife 3 days ago | | |

Deno fired most of their developers.

preommr 3 days ago | |

I am genuinely speechless.

I don't understand the rationale behind how any project, especially of this magnitude, can seriously build something stable this way.

My consolation - and it could be pure cope - is that at least I am in the same boat as a huge company like Anthropic, and they surely wouldn't be stupid enough to also build their cli tools around something that they saw as risky.

feelsbadman.

FergusArgyll 2 days ago | |

For people who still haven't come to terms with AI, this is bad news for the foreseeable future

dolmen 3 days ago | |

I guess that the next release of Claude Code will use that runtime.

No later than next week.

slig 3 days ago | |

This is bad for anyone building on Zig.

dormento 3 days ago | | |

Cue the clueless CEOs of zig shops (I don't know many, but still):

"Rust is faster and safer! Port it! If you don't do it, I'll do it myself, because AI can do everything a programmer can, including the stuff you don't want to do. Ship it!"

phplovesong 3 days ago | | |

Why would it be? There is projects like Roc that did the opposite, they went from rust to zig, as they (had to) use lots of unsafe rust. And before you ask, no it was not an AI generated rewrite.

frangonf 3 days ago |

So the geniuses in the datacenter prefer to rewrite the full codebase in another language instead of maintaining and improving its own fork or contributing to make the current language better.

Impressive to rewrite 1MLOC in a week yes, but this is more of a job of a million monkey programmers crammed in a datacenter than a bunch geniuses. And I would know, since I'm a monkey programmer who is in danger now... Or maybe the Zig team is in a greater danger, since their brains hold the genius juice the clankers are missing and they should have it by 2027...

matt3210 3 days ago |

Anthropic buys bun, makes them spend tokens to convert to rust, nobody understands it anymore, locked into ai now

alfanick 3 days ago |

I'm confused. Never heard of Bun until a few days ago here on HN. It's some nodejs wrapper thingy, written in Zig, and someone decided to use LLM to rewrite it in Rust. Is this a big deal? Who is even using this software? Why is this big?

aarjaneiro 3 days ago |

So many of the code comments on the new port concern only discussion on how it was ported, usually referring reader to the original zig implementation.

So now I'd basically be reading 2x the amount of comments and code to understand _why_ anything is happening.

whateveracct 3 days ago | |

the new code is generally hot ass

defen 3 days ago |

If LLMs can achieve this level of task in 9 days, why do we even need Bun in the first place? Shouldn't we just write our apps in Rust and not even deal with JS?

dheatov 3 days ago | |

Why even rust at the first place? I dont see why we can't go straight from natural language -> Claude -> HTML/JS/CSS bundle. Instead of writing webpage, one can just write prompt for each page and serve it with claude.cgi

morkalork 3 days ago | | |

And if you inject information about the user into the context, everyone can have their own personalized version and we'll turn the internet into the tower of babel where no two people see or experience the same thing.

hstaab 3 days ago | | |

Can a webpage run my factories?

shantnutiwari 3 days ago | | |

>> I dont see why we can't go straight from natural language -> Claude -> HTML/JS/CSS bundle.

Or we could just rewrite everything in assembly, becauase thats fast. Well, Claude can do that. (/s ??)

harrygeez 3 days ago | |

I find that LLMs are quite good at translating code. If you are writing something from scratch you have the burden of preparing something for the LLMs to "translate" from, i.e. prompt or specifications – next best thing to actual source code.

Defining specifications with the level of detail needed to build applications exactly as intended is not as trivial as it may seem.

fold_left 3 days ago |

Honest question, how many of the leaks and crashes can be attributed to zig the language vs possibly (maybe, we don't know) a loosey-goosey, slot machine approach to development heavily reliant on AI? Will the inherent leaks and crashes be fixed, purely by dint of porting to Rust?

pronik 3 days ago |

By reading this thread I've learned that, apparently, you are not allowed to rewrite a large piece of software backed by a large test suite in another language within two weeks otherwise you are a witch and need to be burned on a stake. You are also not allowed to move from the PoC phase to lets-do-it phase within a couple of days without being called names. Why are we concerned with speed all of a sudden? Are we in the "people will literally die if a car moved faster than 25 mph" era of software engineering? Let them do whatever they want, they've shown the will to move on from wrong decisions, they will do it again if the Rust port fails to deliver and the whole industry gets to learn from it, whatever "it" might become.

tvidas 3 days ago |

I don't really understand the point of this. Is it Anthropic showing off well their LLMs work? Was it too difficult to find Zig devs so Bun swapped to Rust? Did Jarred read one too many memes about "rewriting in rust" and took it at face value??

I would imagine that there will be bugs migrating all at once, performance will probably be close to the same, and the maintainers will need to context shift from Zig to Rust. A very confusing decision for sure.

allthetime 3 days ago | |

Claude is significantly better at rust than zig. Zig is changing all the time. If you check my profile comments I did a quick experiment recently to demonstrate. Essentially, Claude could generate a basic working tcp echo server in a few seconds. For zig, either asking it to do it just with zig, or with specific versions (.15 and .16 because some fundamental language changes necessitate different implementations) failed to produce working code in all three cases and also took magnitudes longer to generate the code.

Aside from the big marketing play, Claude not being able to easily generate zig code was probably a big motivator - it doesn’t make anthropic look good and it doesn’t fit into how they’re doing things

Also, you’re assuming that actual traditional maintainers even exist now. Likely it’s a smaller team of people running mythos agents with an unlimited budget and no real need to fully understand the code

nDRDY 3 days ago | |

I suspect one part of the puzzle is that Bun used its own fork of Zig, that had diverged signficantly in design and direction from mainline Zig.

J_Shelby_J 3 days ago | |

The point of it is to hype anthropics IPO.

dcchambers 3 days ago | |

Probably some combination of: Anthropic is heavily invested in the Rust ecosystem and they want their core tools to be built on Rust. More Rust developers. More Rust training data so LLMs write better Rust code than Zig code. Advertisement for Claude Code doing major work on a high profile open source project.

9999gold 3 days ago |

Wondering what they will do when rust rejects a pr from them.

sesm 3 days ago | |

I guess they vibe-rewrite to C, relying on CCC compiler. Agent loop will be modifying both the project and the compiler until the ends meet.

ryanschaefer 3 days ago |

I think one of the things I had forgotten about but sheds some more light in my mind about how this was done is that anthropic bought bun.

The change of tone with the author in the capabilities of Claude. The strategy of merging everything at once instead of a more slow, careful cutover. The “single” author story that every company loves to put forth.

zapnuk 3 days ago |

We should be greatful for this. This is the one public case study on how large-scale llm-driven code generation actually works out.

With node and deno there are reasonable alternatives for everyone who don't want to use bun anymore.

wiseowise 3 days ago | |

> This is the one public case study on how large-scale llm-driven code generation actually works out.

Is it, really? I can't imagine how much money in tokens was spent to get something like this + Jarred's and the teams salaries to review/manage this.

davemp 3 days ago | |

It’s not a public study though. We’re not going to get trust worthy numbers about labor or token cost.

happytoexplain 3 days ago | |

The problem is that many negative effects of this kind of thing won't be clear or immediate, so it's not an easy test to make useful. At minimum, this increases the opacity of the box, reducing perceived trustworthiness.

dgellow 3 days ago |

If the bun team is around I would be interested to get their opinion on this: in the old time migrating a 1M codebase from one language to another meant you would pretty much become an expert in the target language. The output of the work is team experience/knowledge + the actual rewrite. With that Bun rewrite do you feel that the Bun team learned something other than “Claude can rewrite a very large codebase in no time”, which is impressive in itself. Is the output only the rewrite, or did you learn something along the way? And how do you feel about your answer? Not a snark question, like a lot of others I’m myself trying to understand how I feel about how our profession is/has been changing.

randusername 3 days ago | |

I used to think software was inherently valuable.

Then I decided that software is of limited value without a team to maintain it. Not necessarily because they fix it, but because they represent a bunch of humans who collectively understand it and therefore give it more possibilities.

And now this. I'm not sure what to make of it.

dgellow 3 days ago | | |

Same

gib444 3 days ago |

Maybe a good advert for Claude; but a terrible, terrible advert for the stewardship and governance of the Bun project.

zx0r23 3 days ago | |

This is the most accurate take lol. Claude's done impressive work, but I would absolutely never trust this project in production now.

manlymuppet 3 days ago |

Software is only as good as the end result; it doesn't matter how we get there.

There is reason to be suspicious of LLMs, but people should stop getting so wrought up over _how_ the Bun team writes their software, until they have complaints over the software itself.

Just let the team do their thing. You're free to reject the end result.

giancarlostoro 3 days ago | |

I agree, if the code gets tested endlessly, and audited, and nobody, not even the LLM can find major jarring issues with it, it compiles, builds, and works as expected, isn't degraded in any way, I don't think I care how you built the "new" rendition of the software.

LucidLynx 3 days ago |

Is this really the state of "software engineering" today? :/

wiseowise 3 days ago | |

You'll pay for tokens and you'll be happy.

gmueckl 3 days ago | |

That's what the new AI overlords want the world to believe, at least.

registeredcorn 3 days ago | |

mushware*

pl-nerd-9000 3 days ago |

I just skimmed through the porting guide and based on the number of unsafe blocks, this looks like a fairly straight-forward mechanical translation.

If that is the case, why didn't they just "vibe-code" a Zig->Rust translator and a small Rust/TS/JS/whatever script to orchestrate things. You don't even need pretty printing support because rustfmt exists.

You'll save on a bunch of tokens, probably a lot of time/enegy, the process becomes auditable and (hopefully) deterministic, and if there's a mass bug in the translation, you only have to fix it in one spot.

mplanchard 3 days ago | |

Bun is owned by anthropic. They get infinite tokens, and anthropic gets a fluffy PR piece slash advertisement.

ozozozd 3 days ago | |

No time for common sense solutions! Tokens gotta go somewhere!

fg137 3 days ago | |

But... But... It's going to be harder for them to claim "AI did the rewrite"!

TeriyakiBomb 3 days ago |

I hope the Deno lot take the opportunity to capitalise on this

tuananh 3 days ago | |

This is their chance for sure but it seems they are scaling down, at least their main product Deno Deploy.

Prev they have presence in 31 regions but now it's down to just 6

https://docs.deno.com/deploy/classic/regions/

culi 3 days ago | | |

Bun's rise over Deno is honestly shocking. One man's project that went viral because of some very misleading benchmarks has evolved into a behemoth in an incredibly short time frame. Some major projects bought into the benchmarks and adopted it for important projects and thus it was thrust into stardom.

I was naive enough to believe Deno's ascendance was all but guaranteed with Ryan Dahl's name on it and the direly needed security guarantees it offered.

veidr 3 days ago | |

By having Codex port Deno to Zig, you mean?

ramon156 3 days ago |

I'm a pretty reckless programmer, but I would never do it on a project this big... 1m LOC cannot be reviewed in <1 week. Why not put it behind a feature flag, since you're keeping the code anyway (only -4k LOC).

This does not seem thought out, and was fueled by dopamine.

q3k 3 days ago |

  $ grep --exclude-dir=.git -r 'unsafe {' | wc -l
  10465

Nice.

K0nserv 3 days ago | |

It's not that weird to end up with this when translating C/Zig/C++ to Rust. A first pass can use unsafe and then when the code is in Rust you can work on reducing the unsafe.

Trying to eliminate all unsafe as part of the rewrite, whether done by human or LLM, would be making too big of a change in the process of rewriting.

q3k 3 days ago | | |

> would be making too big of a change in the process of rewriting

God forbid the already unreviewable -710kloc/+1mloc change get any bigger!

janice1999 3 days ago | |

The benefit of using Rust is that you know exactly where the unsafe code is so you can handle it explicitly and deliberately to avoid issues by imposing carefully crafted constraints... oh.

ibejoeb 3 days ago |

Github is failing to load the 800 comments, naturally. I'll bet they're fun.

xigoi 3 days ago | |

Too bad modern computers are not capable of processing 800 paragraphs of text. That’s several hundred kilobytes! Maybe the technology will advance thanks to AI…

a96 2 days ago | | |

This is your* computer on Microsoft.

* someone else's

Imustaskforhelp 3 days ago | |

Github actually made my computer lag when there were no comments at all because of the 1 million lines of code added iirc. I could've responded something first but well I wanted to say something meaningful and didn't have anything so I just closed it.

I had to literally force quit my browser because of how much it lagged iirc.

pixelesque 3 days ago | |

6,755 commits for the PR as well...

phplovesong 3 days ago |

RIP Bun.

Im feeling like i won the lottery that i picked deno over bun a few years ago for a bigger project.

electronsoup 3 days ago |

So how many of their employees are now familiar with the codebase? zero?

culi 3 days ago | |

I mean if you look at the code, it's a pretty faithful rewrite. It seems like being near 1-1 with the original code was prioritized even more so than utilizing Rust's safety features since unsafe Rust is everywhere

christophilus 3 days ago |

Well, that escalated quickly. I think I first heard rumors of this a week or two ago. That's a very vast turnaround for such massive code-churn. I don't know how to feel about this.

CGamesPlay 3 days ago |

Given Anthropic's existing track record of producing terrible hallucinated inaccurate documentation in Claude Code, I'm very curious how Bun will handle this as it continues development. Anthropic probably doesn't care about Bun's external compatibility as long as it runs Claude Code. Will Bun be eventually become "the JavaScript flavor that Claude Code uses"? Will they even bother updating external documentation as it changes? Docs currently live at https://bun.com/reference, but I don't know how much of this is separately maintained documentation versus JSDoc-style generated documentation.

ivanjermakov 3 days ago |

I hope it's obvious why I'm removing Bun dependency in all my projects. Would be great to have a non-affiliated zig-bun fork that focuses on, well, runtime.

sudb 3 days ago |

If this means that segfaults become rarer with Bun I might consider using it in production again. As it stands, Bun has been great as an all-in-one TS/JS package manager, build system and test runner but unstable enough that I still want Node running in production backends.

xigoi 3 days ago | |

Surely there are no bugs in the 1000000 lines of code that no one has reviewed…

sisve 3 days ago | |

Yes. That is the plan.

See jared comment [0]

If this helps bun and rust is a better lang for developing bun going forward with the help of claude. Then i think that is just fine.

I thought rust was making the codebase complex so zig won on speed and dx.

But with llm and a large codebase it seems like rust gives fewer bug and you can develop it faster & safer.

https://news.ycombinator.com/reply?id=48133519&goto=threads%...

makotech221 3 days ago |

first major company to really nuke their main product via AI psychosis?

ezekg 3 days ago | |

Yes and no: https://www.anthropic.com/news/anthropic-acquires-bun-as-cla...

supern0va 3 days ago | |

I for one think it's a fascinating experiment to see how well it goes. Though if it actually works and leads to bun getting better over the coming months, I suspect the arguments against it will just take on a different flavor.

Tesl 3 days ago | | |

Of course they will, the goalposts will keep shifting because people don't want to admit that agents are now this capable.

tkel 4 days ago |

Turns out "its just an experiment, you all are overreacting" was just a lie to damp criticism.

https://news.ycombinator.com/item?id=48019226

scuff3d 3 days ago |

Congratulations to everyone who uses Bun. You're now working as alpha testers for Anthropic... for free.

Anyone using Bun should consider migrating away immediately. Not because of the LLM angle, but because of how insanely irresponsible this is.

lioeters 3 days ago | |

I reviewed the million lines of code added in a week, and I'm horrified. Not running that thing on my machine.

TheMiddleMan 3 days ago |

This may be the largest AI-generated codebase right now, by a lot. It'll be interesting to see how this plays out.

Frontier AI software development still falls short in the design/architecture department, in my recent experience. Though it's pretty impressive at making "working" code.

This being a fairly direct conversion from one language to another, even keeping the same interfaces across files, means the architecture is already in place.

The detailed test coverage is also very helpful for Claude. But even detailed testing can't cover every edge case.

So my questions are: How well did Claude do on the edge cases? And how maintainable will this codebase be going forward?

KronisLV 3 days ago | |

> This may be the largest AI-generated codebase right now, by a lot.

I'm sure there's lots of other large scale applications of AI, just not many/any projects that are open source and so high profile - with the changes being done so far.

Personally, in the past 3 months I've shipped about 2.3M lines of a legacy project migration, though the new codebase is Java + Oracle ADF because of reasons™ and instead of being an interesting codebase, it's more forms heavy and essentially acts as a front end for a large Oracle instance, think more CRUD than application runtime (with an upsetting amount of XML).

The difference also is that it wasn't migrated by using AI on every file, but rather dumped the DB schema into JSON, and converted the old form contents to a YAML intermediate format that describes what's in the forms and have been iterating ever since of creating code that generates code - basically AI assisted development of a codegen solution + AI assisted sidecars that get merged with the generated code based on markers, when something can't be automated that way and often times also AI controlled browser based testing (since Playwright is in the cards for everything, but not yet).

Seems to be going pretty okay so far, will probably take months more of iteration and fixes, currently the automated testing is taking a while because let me tell you - not only Oracle ADF is shit, but so is WebLogic, like fuck I'd be so closer to being done if I was allowed to pick Python + HTMX or even Java + Thymeleaf. That's still better than a team spending a year on the migration and getting like 10% of the way there.

Obviously there's no more details to publicly share, but the overall vibe is clear: as long as you can test any changes, you can iterate faster than without AI - and the code ends up being more readable that colleagues would often write. The problem is that people would squint at the suggestion of 100% test coverage previously so most code is even written in a way that is straight up not testable (and often nothing is decoupled from the framework properly and tests take way too long, both time and resources).

ninjahawk1 3 days ago |

“+1,000,000” changes in a single commit is insane.

mrweasel 3 days ago | |

Why would they do it like this? It makes no real sense to me. At that point it's an entirely different project, with the same functionality.

If you use Bun in production, does this feel like a well managed upstream?

I don't use Bun, I don't care that they are using an LLM (though it is impressive that this actually worked), but the project management aspects of this is just wacky.

preisschild 3 days ago | | |

Because Anthropic owns Bun and they use it for marketing purposes.

ahepp 3 days ago | |

The really interesting thing to do would be to ask the agents to submit the diff as a coherent patchset...

dluan 3 days ago | |

> "The codebase is otherwise largely the same. The same architecture, the same data structures."

ihateolives 3 days ago | | |

Ship of Theseus.

paulddraper 3 days ago | |

And 6700 commits.

eqvinox 3 days ago | | |

No wonder GitHub is down

feverzsj 3 days ago |

How they gonna do refactoring, bugfix or other maintenance on generated code? Ask LLM?

pixel_popping 3 days ago | |

Yes, only LLMs from now on.

nDRDY 3 days ago |

Why didn't they ask Claude to remove all of the `unsafe` at the same time??

dolmen 3 days ago | |

"at the same time" is a recipe for failure with coding agents.

veidr 3 days ago | | |

It's also a recipe for failure for ports in general. Same goes for the "not idiomatic Rust" comments above — that would be nonsense.

You want to port it as faithfully as possible to the original, porting it bug-for-bug, quirk-for-quirk. Then, over time, after the port has been proven to be as identical to the original as possible, you can gradually fix those kinds of internals.

That's why TypeScript's tsgo native port is so good.

nDRDY 3 days ago | | |

Right, so what we have here is a very expensive regex.

linkregister 3 days ago |

Source: https://github.com/oven-sh/bun/pull/30412

j-pb 3 days ago |

On one hand I kinda feel validated for having jumped ship on Zig 3+ Years ago[1] and moving everything to Rust[2], with the language simply being too unstable and unsafe in my eyes, despite my love for comptime and people arguing that Bun and Tigerbeetle were proof that it wasn't the languages fault.

But I also feel bad for the Zig project to loose one of their flagship projects, because while I find the project ultimately anachronistic, I know what it's like to pour your sweat, heart and soul into something, and having it replaced within a week is a sobering experience even from afar.

A couple years ago this would have been unthinkable because of how slow legacy codebases and rewrites are.

I wonder if Tigerbeetle will also have problems arguing for their solution now that the other project they can point to for customer assurance is gone. And I wonder if they will follow suit eventually simply due to marketing pressure (after having been bitten by the Zig compiler I was surprised that they were putting their super duper high reliability database on top of it at all, but with another big player using it there was at least some peace of mind for their enterprise customers).

1: https://github.com/triblespace/tribles-zig

2: https://github.com/triblespace/triblespace-rs

jorangreef 3 days ago | |

> I wonder if Tigerbeetle will also have problems arguing for their solution now that the other project they can point to for customer assurance is gone.

In general, we never like to appeal to popularity (a logical fallacy), but why would you assume here that we would point to Bun specifically (or any project for that matter) [1] as an example of Zig’s quality?

We prefer to judge Zig’s quality on its own intrinsic merit:

For example, we subject the language through TigerBeetle to inordinate amounts of fuzzing, perhaps more than any other language (you could say Zig is lucky to have TB’s test suite aimed against it!).

Literally 1,024 dedicated CPU cores, 24/7.

Zig holds up remarkably well.

We also recently pledged $512K to the ZSF, together with Synadia.

These are the kinds of things we prefer to point to. Not hype, but real end-to-end systems engineering, and long term financial support, regardless of the language we choose to use.

[1] I picked Zig back in July 2020. At the time, the largest project was River, but already Zig was a phenomenal choice, and the years have only shown that Zig was probably one of the best design decisions in the development of TigerBeetle. It turned out better than I imagined.

j-pb 3 days ago | | |

Correct me if I'm wrong, but the three largest Zig project (by far, with a huge gap between them and the rest of the pack) are Bun, Ghostty, and TigerBeetle.

A language so niche that it only has 3 major projects is a liability. Now it has 2 major projects, one of which is yours. Even I as a weird language connoisseur would raise an eyebrow at that.

After switching from Zig to Rust, I felt like the language was helping me improve the correctness of my project, to argue that the fuzzing of your project helps improve the correctness of the language feels backwards and adds to my suspicions.

We both know that fuzzing is great, but that wether you fuzz with 1000 cores or 1.000.000 cores, at an exponentially growing state space it doesn't make (that much of a) difference (I know that you guys are not doing naive fuzzing, which is extremely cool, but the shape of the problem is still O of evil shaped). Most things you can find with fuzzing are shallow-ish, and if you want to go deeper you need formal verification (for which a strong type system is a good first approximation and I'm not aware of something like Kani in Zig).

I like TigerBeetle and I still wish you guys all the success in the world, but I can't help and wonder where you could be by now if your language was lifting you up, instead of you having to lift up your language.

jrpelkonen 3 days ago | |

While I don’t have personal experience with either project, I feel it is safe to say that Bun and TigerBeetle are not comparable projects: TigerBeetle has a strong focus on testing and correctness, and Bun maybe not so much. IIRC, TB did well in the Jepsen test and had one segfault in a client library. Bun has had quite a few memory safety issues, in fact, the stated motivation for the Rust move is to eliminate those going forward. We shall see how that pans out.

nDRDY 3 days ago | |

I doubt the Zig maintainers will miss the giant PRs from Bun!

j-pb 3 days ago | | |

I'm pretty sure they'll miss the full developer salary that Oven used to sponsor them, which they no longer do. I'd wager one doesn't do a rewrite like that, if you are in great personal standing with the language foundation.

That same "just don't use it" attitude was what drove me away from Zig btw. I would have been fine in restricting myself to a somewhat stable subset, e.g. if, loop + function calls, but they didn't want to provide any tiered stability guarantees for the language.

Opinionated is great, no local minima is great, but you have to accept that if you don't want to engage with the needs of your (professional) community then what you do is a hobby project. A very cool hobby project beloved by thousands, but a hobby project.

KronisLV 3 days ago |

That's pretty... brave? Not releasing it in parallel and spending a few months testing it against the old mainline version to surface issues BEFORE a potential merge?

ukblewis 3 days ago | |

Who knows what their release strategy will be. This is still only a canary release. Don’t put your horse before your cart

WhyNotHugo 3 days ago |

One of Bun's longstanding issues was that bootstrapping Bun required Bun, so distributions were unusable to ship it or anything that depended on it: https://github.com/oven-sh/bun/issues/6887

Any ideas if this is now changing and Bun can be bootstrapped with "just" Rust?

Havoc 3 days ago |

How does the no async work? Would have thought Bun would need that

lukaslalinsky 3 days ago | |

People were doing async I/O before coroutines existed. They are using callbacks and their own networking.

valzam 3 days ago | |

Async presumably happens in the JS runtime that bun calls into. Just need 1 thread to host that

deadbabe 3 days ago |

To me the interesting thing to watch about this project is that if it fails and Bun becomes a piece of shit even with all the resources at their disposal, it means LLMs are probably not going to be the revolutionary tech everyone has been hyping it up to be. It’s useful sure, but software engineers aren’t going away. How could anyone interpret this any other way?

RobLach 3 days ago |

Rust needs to remove the unsafe keyword to finally fulfill it's destiny as a practical LLM generation target.

nesarkvechnep 3 days ago |

The average quality of the Zig projects got up.

poops 3 days ago |

1 million additions. 4k deletions. 0 approvals.

janice1999 3 days ago |

Has he estimated the token cost for this (if he had to pay that is)? I'm curious how much this would cost a paying customer.

dolmen 3 days ago | |

Bun is owned by Anthropic.

This is just marketing budget.

tuananh 3 days ago | | |

The acquisition money is coming from marketing budget :D

phplovesong 3 days ago | |

Probably in the six figures.

zipy124 3 days ago | | |

Depending on the model I could easily see it approaching 7 figures since Mythos security scans have been 6 figures already and don't require nearly as much output.

jauntywundrkind 3 days ago |

What does this mean for bun add-ons like opencode's opentui? Did FFI also somehow get ported or will that have to be updated? https://github.com/anomalyco/opentui

0x457 3 days ago | |

First, why are you calling it "add-on". Second, it's done via the same C ABI.

jauntywundrkind 3 days ago | | |

Node's been calling native code distributed in a npm package "add-ons" for a decade and a half.

Fair call on the same C abi. Adapting to node 26.1.0's new FFI is happening in https://github.com/anomalyco/opentui/pull/104 . There's also some new FFI adapters opentui is adding there, and they're adding a worker.

So there is some adaption. That was sort of the interesting useful actual look I thought might be informative, where-as I feel like you were mostly just trying to be curt & maintain a status quo of keeping us all uninformed/unknowing. Let's try actually providing useful steps forwards when we post, ok?

HEX4AGON 3 days ago |

I'm curious how much dollar in LLMs this rewrite cost

mapcars 3 days ago |

>No async rust.

I wonder why does that deserve an explicit statement? Is there anything wrong with async rust?

andai 3 days ago | |

I don't know their reasoning (not much Rust) but this was on the front page last week:

Async Rust never left the MVP state

https://news.ycombinator.com/item?id=48019163

rpunkfu 3 days ago | |

Because bun controls it’s own runtime and event loop in particular way

jjgoi 3 days ago |

https://github.com/oven-sh/bun/pulls

and now we have lots of troll PRs...

lgl 2 days ago | |

> People keep opening issues about "unsafe usage" in the codebase. This PR solves that problem at the root by introducing a yolo! macro and replacing all 10,421 instances of unsafe {} across 732 files.

This is actually pretty funny.

bharxhav 3 days ago |

This canary will never leave the mine. (unless Anthropic opens their wallet again)

lucasloisp 3 days ago |

The follow-up PR removing the zig source files being auto-tagged by bun's own CI as "ai slop" is so funny

https://github.com/oven-sh/bun/pull/30680

Jarred 3 days ago | |

That was me - not CI marking as slop. It kept around 60 .zig files around that should’ve been moved to .rs files.

aarjaneiro 2 hours ago | | |

Then why did you open the pr...?

tempaccount420 3 days ago | | |

It looks like you were spamflagged on your last comment https://news.ycombinator.com/item?id=48133806

That's wild, how are people going so crazy over a rewrite.

ksec 2 days ago |

What I would like to see, is Bun to even further improve all the test that was missing during this Bun Zig to Rust code translation. ( I wouldn't even call it a rewrite ). And additional test during Zig and Rust running parallel in A/B testing.

And then with those tests, ask Claude to translate the Zig Bin to Go and Java again.

lackoftactics 3 days ago |

With weird sadness I have to say, we are getting targeted with new kind of marketing. It doesn’t look like it was just technical decision. If anyone was following what was going on X, it was crazy with amount of content about it.

I couldn’t believe before with all fearmongering being marketing, but I am coming to conclusion it is. It’s hard to get any signal over noise in attention economy. They know what they are doing and it’s Deja Vu of crypto, but now we are targets with rage baits, guerilla marketing, buzz

ivanjermakov 3 days ago |

For those looking for an alternative no-compilation TypeScript runner, I'm quite satisfied with TSX: https://github.com/privatenumber/tsx

Node.js itself is getting quite close to running TypeScript natively, but they don't support using ES imports of CJS packages and importing with no-extension qualifier.

kreco 2 days ago |

Worth mentioning that the whole git history is gone, the Rust code does not have any human crafted history, which entirely defeat its purpose.

Also, with a million line of code unreviewed by humans, there could be some sneaky backdoor in it.

This makes me think that people are actually under-reacting to this Bun rewrite.

postalrat 2 days ago | |

I use bun and never thought human crafted history was its purpose.

sesm 3 days ago |

I wonder, did they consider an approach of vibe-coding a deterministic converter and then running it? This should be much more token efficient.

saltyoldman 3 days ago |

Probably goes without saying but they probably had it check out thousands of projects that use bun and compile them using the new rust binary. And that was probably all automated and lifted into a compute structure that probably did all of that testing in 20 minutes. these people have scale.

atonse 3 days ago |

I have full faith, it's the same really smart people that built bun (Jarred and team) that have spearheaded this and are running it. So I have no reason to believe that this was done carelessly.

That said, I'm still shocked and amazed that something this big is possible these days. But as we've seen multiple times now, one of the most important things your codebase can have is a solid test suite.

I will continue to use bun, because at the end of the day, it isn't just the technology, but the talent/people behind the technology that ensures that it will be solid.

And since that hasn't changed, I will still trust bun and its direction.

Also, bun is mostly glue code and sort of "user space" libraries (my words) as Jarred has said on X, most of the underlying runtimes like JavascriptCore, etc weren't rewritten.

So this isn't like 100% of what we think of as bun was rewritten. It's more like the scaffolding and harness.

ifwinterco 3 days ago | |

Just because it's possible, doesn't mean that it's sensible

bigstrat2003 3 days ago | |

> So I have no reason to believe that this was done carelessly.

Writing software with an LLM is doing it carelessly.

moomoo11 3 days ago | |

yeah but it also made some tests pass by changing the tests. i’m not super familiar so i’ll dig more on weekend but it seems sus pending more review. i’ve had ai do similar things that i caught in manual review. cheating the test is bad.

gmueckl 3 days ago | | |

It is welk known that agents can cheat or go off on tangents and not recover. Just recently deleted a bunch of code files that I didn't ask for. The code wasn't even used anywhere.

atonse 3 days ago | | |

That's why they've merged it into canary so they can continue working on it.

zx0r23 3 days ago | |

Doesn't doing this in the matter of a week or so, by definition mean it was done carelessly?

How could it be possible to test such a complicated piece of software, and review such a large amount of code in such a small timeframe? Spoiler, it's not. They're merging slop.

atonse 1 day ago | | |

It would mean it was done carelessly if it was done by a human in a week. Or if the test suite was sloppy. But it was done by an AI in a week.

We have to change our perception of time with AI. An AI can read war and peace in half a second.

serial_dev 3 days ago |

I wonder if the whole acquisition was done so that they have guinea pigs that can’t say no…

or if I want to be cynical… so that they have a big enough project where they can force gigantic rewrites without considering the outcome from the project’s point of view, all so that they can fuel their marketing strategy.

To be honest, kind of obvious looking back.

PudgePacket 4 days ago |

+1,009,257 -4,024

wild

andrepd 3 days ago | |

Least unstable js project

bogdiyan 3 days ago |

I wonder what portion of the migration was contributed by Mythos. Surely the Bun team now has access to more powerful models, but could such a migration be done with just Opus 4.7? Nonetheless, nearly 7k commits is impressive.

baq 3 days ago |

I low key hope a codex shop, perhaps OpenAI themselves, do this too, so we can compare results.

padjo 3 days ago |

Will be interesting to see how this pans out. Some people will see minor issues as proof that AI is terrible, but honestly if this gets released and is relatively uneventful it just highlights how the art of building software had changed completely in the last few years.

insin 2 days ago |

Congratulations to the Anthropic marketing team on their acqui-hire.

mghackerlady 3 days ago |

This is kinda sad, I liked having bun as a good example of software in Zig

sutib 3 days ago |

"And Icarus laughed as he fell, for he knew to fall means to once have soared"

simpsond 3 days ago |

This is a wild experiment! I do think the incentives are heavily weighted to Anthropic for this to go well. I have mixed feelings about how it will go, but it will result in an important outcome…

ChocolateGod 3 days ago |

Hopefully this means Bun can now support things that were limitations of the Zig libraries like being able to upgrade standard TCP sockets to tcp without closing them.

3asjUas 3 days ago |

The result is so horrible that Anthropic will quietly move to Node in 6 months. Now they got their headlines and in 6 months everyone will have forgotten about it.

qustrolabe 3 days ago |

It's cool how you can just do this now in 2026. I hope it gets cheaper and easier to do with other big projects written in outdated or just not good enough languages

arjie 3 days ago |

Huh, it makes sense that Anthropic acquired these guys. This kind of AI nativity in thought directing to action is actually incredibly uncommon.

AirMax98 3 days ago |

Probably one of the most reckless things I've seen in software. Beyond safety or quality, at the very least: what about all the existing contributors' PRs? Fuck 'em?

kracket 3 days ago |

It's going to be absolute mess of total AI slop and black box that nobody understands and is going to cause more issues than it fixes.

vitaminCPP 3 days ago | |

Yep. How will we manage those 10x code projects, when LLMs cost increases by 10x?

philipbjorge 3 days ago | |

I've done some pretty incredible things with LLMs. If this were sqlite with its exhaustive test suite... OK, I can see it.

It's hard for me to see this not becoming a pile of slop, but hey, maybe I'm wrong

pier25 3 days ago |

This will burn the little reputation and trust Bun has been able to achieve in the past couple of years.

I guess this is what happens when you only have to respond to your corporate overlords.

I will migrate my Bun projects in production to something else.

rubenfiszel 2 days ago |

Would be very cool if as a result the different components were published as crates and embeddable in other rust projects!

wateralien 3 days ago |

Deno's approach from the beginning seems to have proven out.

tuananh 3 days ago |

For those daring to put this in production: you're crazy!

youio 3 days ago |

9 days to review +1million LOC in Rust is enough? wow..

dom96 3 days ago |

I'm curious where this leaves Zig. Bun was the most prominent and biggest project using it. What's left?

peesem 3 days ago | |

TigerBeetle (https://github.com/tigerbeetle/tigerbeetle) and Ghostty (https://github.com/ghostty-org/ghostty) come to mind as decently popular projects.

chillfox 3 days ago | |

I though TigerBeetle was the biggest Zig project. Anyway, I am sure there's plenty of projects in Zig out there.

allthetime 3 days ago | |

Zig is still a moving target with big fundamental changes being made to the language from version to version - nowhere near v1. When rust was at this stage of its development you wouldn’t have been able to name many projects either.

sergiotapia 3 days ago | |

It leaves it in the same vibe realm as Nim. A terrific language but probably never hitting mainstream. You're familiar with Nim. ;)

dom96 2 days ago | | |

Doesn’t seem like it is in the same adoption realm. I wasn’t aware Ghostty was written in Zig and I’m not aware of any Nim project ever reaching the heights of Ghostty (or indeed Bun). Plus as others state, Zig is still pre-1.0.

Things do look significantly better for Zig adoption-wise than for Nim as far as I can tell.

mattrighetti 3 days ago | |

Ghostty

lazzlazzlazz 3 days ago |

Where are all the guys in the Hacker News comments who have been explaining how bad LLMs are?

koiueo 2 days ago | |

LLMs bad¹ ² ³ ⁴

¹ when they empower idiots who vibe features with no regard for tech debt

² in a long run when they are used without human oversight

³ even on trivial tasks when results can't be reliably verified (f.ex. tests coverage)

⁴ the above list is not exhaustive, but outlines main points which should be easily recoverable (by any person smarter than a house spider) from the context of discussions involving LLM sceptics.

To answer your question "where" – take this as your home assignment. My message contains enough hints to come to the right answer.

prashantk_ 3 days ago |

This is a massive marketing for Anthropic. It shows how capable their systems to enterprises customers.

Also this is a perfect task for LLMs. They have the most detailed spec (Production Zig code) ever, and since it as file for file and line for line rewrite, agents were able to quickly complete a massive 1 Millon line rewrite.

We will continue to see more of these in future.

classicposter 3 days ago |

It's interesting that the developer who spearheaded the hype of Zig abandoned the engineering without addressing the segfault. They could have also taken the approach of gradually porting from Zig to Rust via FFI. Yes, this is a slop show by the AI lab.

Herbstluft 3 days ago |

I mean aside from the somewhat...dishonest statements from the people involved, giving false explanations is one thing, but calling people who smelled this "overreacting" gives this a weird taste.

I am neutral on such a rewrite itself, there are pros and cons to the whole "rewrite in Rust" topic. People are making decent arguments. But the way the initiator here reacted makes it seem like the Bun team itself thinks they are doing something weird here...

Guess reviewing any code isn't exactly their thing either anymore? And I guess adjusting the tests themselves is certainly one way to make things pass.

Ultimately this just seems like it was done specifically to make Bun more "ai friendly". Whether it turns out good or not that appears to be the motivation behind it.

ptrl600 3 days ago |

Hey, it forgot to change the README!

ares623 3 days ago |

Anyone using Bun in production excited for this release? (other than Anthropic of course)

kracket 3 days ago |

The bun is down the drain.

rglover 3 days ago |

Well this is uncomfy. Not what...a week ago this was just framed as an experiment and now it's being rammed through?

Even if it works/is correct/etc, this is shockingly careless.

If I'm going to be using your thing to build on top of, I sure as hell don't want to see you 180'ing a week after you just said you weren't going to do exactly what you just did.

Hard pass, purely on principle.

4b11b4 3 days ago |

I can't imagine doing this to my own code base lol. I suppose only after Anthropic gave me a lot of money I'd say hey fuck it let's find out

minikomi 3 days ago |

Now translate it into zig!

gaucheph 2 days ago |

i wonder if claude could "round trip" the port back to zig from rust

KolmogorovComp 3 days ago |

It shows that the choices/philosophy chosen by Zig isn’t the right one and that memory safety is still too boring/hard to handle at scale.

deathanatos 3 days ago |

I feel like there's an iron triangle here, that involves "is vibe-coded", "is secure" and "accepts bugfixes".

Like, you didn't review that 1M LoC. There's no way to have done so. If we're accepting slop-fest PRs, then nothing stops an attacker from burying a security bug in a slop-fest PR that then gets reviewed. And if I'm the attacker, I'm crafting that security hole to have subtle clues to the security AIs reading it as to why it's "correct" so that your AI review bot goes "oh, yeah, this logic works".

jwpapi 3 days ago |

This will go down in history as the biggest mistake of software engineering of all time.

Bun is the runtime of Claude Code, which is the core product of a trillion dollar company, which now sits on a vibe-coded app, where not a single person in the world has a proper mental model of.

ageitgey 3 days ago | |

I don't know, there's been some pretty bad software mistakes, possibly bigger than a PR to convert an app to Rust:

https://en.wikipedia.org/wiki/Therac-25

PyWoody 3 days ago | | |

Can't forget Knight Capital: https://en.wikipedia.org/wiki/Knight_Capital_Group

auguzanellato 3 days ago | | |

I hope no one ever builds (or even worse, vibe codes) a radiation treatment machine.

applfanboysbgon 3 days ago | |

Claude Code itself is purely vibecoded, both CC and Bun leads are saying that humans are not writing code at Anthropic anymore. It is amazing how much money they intend to squander, because it's all funny money to them, investors just give it to them hand over fist for them to burn. Developing wrappers around the model isn't even the hard part and yet they're going to burn themselves to the ground getting high on their own supply.

NitpickLawyer 3 days ago | | |

> Claude Code itself is purely vibecoded [...] money they intend to squander [...] going to burn themselves to the ground getting high on their own supply.

This really really really isn't the burn you think it is. Going from 0 to 2B+ in revenue from a "purely vibecoded" thing is what they've said they're doing, and what they've actually done. Like in already done. It's not going back, no matter how many nuh nuh people write. They've already shown this can be done.

People will continue to think that this is some sort of a gotcha. But it's actually precisely what they've done: they showed that dogfooding works. If this works, why not x y z?

nicce 3 days ago | |

Maybe this is the best marketing trick for Claude Code ever. Maybe there was pressure from Anthropic to do this and prove the value. Even partial success is enough to prove the value, justify the value and usage, and AI dependency even further.

tarruda 3 days ago | | |

And as long as Bun doesn't break Claude code, which only uses a subset of it's APIs, this might just pay out.

ares623 3 days ago | | |

It only needs to survive long enough for the IPO

IshKebab 3 days ago | |

My initial reaction was that this is pure insanity but in fairness this is a fairly 1:1 port of existing code, so the developer's mental model of it should still match fairly well.

For instance look at this Zig function: https://github.com/oven-sh/bun/blob/ed1a70f81708d7d137de8de0...

Versus this Rust version: https://github.com/oven-sh/bun/blob/ed1a70f81708d7d137de8de0...

I did pick that at random but it does look like the best case. I skimmed through a lot of the Rust code and there's a surprisingly small amount of `unsafe`.

Still pretty insane to merge this in such a short time with so little testing, but I can easily think of bigger software engineering mistakes. Hell it's not like Bun even needs to be commercially successful any more.

jwpapi 3 days ago | | |

It’s still 400k more lines

mapcars 3 days ago | |

On the other hand they might be super confident in the results, and if it goes well they might use is as an example of how good claude is

keyle 3 days ago | |

Won't touch it with a ten foot pole.

a96 2 days ago | |

No. Shenanigans in a neverheard js project isn't going to be in any history outside of their own niche.

pixel_popping 3 days ago | |

Well, realistically as well, humans gave us softwares that are full of security holes (and bugs), which one have you seen that a human perfected on the first time around? Give AI some time as well to be fair.

dheatov 3 days ago | |

I for one am REALLY GLAD to see it consumes itself.

jwpapi 3 days ago | | |

How life feels not using bun

aiscoming 3 days ago |

vibe coders keep saying that now you can have 100x productivity, that you can write a million lines of code in a week and do what would take a team of 10 experienced developers a year.

where are all these million lines vibe coded projects? I don't see them. its all hype

andai 3 days ago | |

This PR appears to be over a million lines (though GitHub won't load for me).

Of course the quality is the real question. I haven't had amazing results with LLMs with Rust, but they're less bad at it than they are at Zig, which is probably the reason for the rewrite.

At least in this case the original code was written carefully by hand, so the design is sane, and now just the auto-translation is in question. Now it just needs to be battle tested.

pixel_popping 3 days ago | |

Bun is now literally vibe-coded, that's your proof. And Bun developers will solely use LLMs at some point (pretty close to "vibe coding").

q3k 3 days ago | | |

Show me some gold instead of a continuous stream of pickaxes.

yoyohello13 3 days ago | |

Bun is now the example. It's >1million lines of code, entirely vibe coded. All we do now is wait and see what happens.

FergusArgyll 3 days ago | | |

Yeah, I believe op is using sarcasm (see username for one data point)

sionisrecur 3 days ago |

I wonder if projects like Ladybird will try this approach now. They've been trying to move to Rust (after trying Swift first) for a while.

tabs_or_spaces 3 days ago |

Why would you replace an existing codebase like this instead of forking the repo instead and then making the changes?

tredre3 3 days ago | |

They did fork it initially to experiment, then decided this experiment would go forward and thus naturally belong in the main repo.

Git has this branch concept. It's being used correctly here, IMHO.

docmars 3 days ago |

I hate to say this, but this reeks of "We're owned by Anthropic now and we were put to task to prove Claude Opus as the ultimate AI model, so we were forced to do a full port of something millions of developers rely on to Rust in record time. Just ignore the slop and unsafe statements." (sweeps the broom)

This is nothing more than a marketing stunt from Anthropic. Nothing to see here.

kursus 3 days ago | |

> millions of developers

Try a few thousands.

docmars 1 day ago | | |

(This man hasn't seen a hyperbolic exaggeration before)

It's alright, I forgive you :D

In truth though, the repo is approaching 100k stars and bun has over 7 million monthly downloads. My point still stands.

hacker_88 3 days ago |

Time to fork it for zig

nDRDY 3 days ago |

Giant slop-filled PR (that will power future slop-generation) has caused slop-coded Github to stop loading properly.

The Anti-Singularity is approaching ever quicker!

sponnath 1 day ago | |

It's actually baffling that Github struggles to load a 1000 comments. It can't even load a single one it seems like. It just straight up silently fails. How is this a thing in 2026?

parliament32 3 days ago | |

It's okay, at this rate Anthropic will be the only ones left using Bun.

This is the Extinguish phase of the process, right?

elwesties 3 days ago |

This is so awesome! What a time to be alive that something like this is possible.

veidr 3 days ago |

We have hundreds of projects that run on Bun. (Some are Bun-specific for whatever reason, but most are "runtime-agnostic TypeScript code that runs on Bun, Node 24.2+, and Deno, but that means they run their test suites on Bun, in addition to the other two.)

Out of curiosity, I installed the canary Bun and just ran a bunch of them. It didn't take me long to find one that works on stable Bun and crashes on "canary" Bun.

      schematic git:(main)  bun upgrade --canary
    [1.55s] Upgraded.
    
    Welcome to Bun's latest canary build!
    
    Report any bugs:
    
        https://github.com/oven-sh/bun/issues
    
    Changelog:
    
        https://github.com/oven-sh/bun/compare/0d9b296af...19d8ade2c
    
      schematic git:(main)  bun run main.ts serve
    Schematic Editor running at http://localhost:4200
    Bundled page in 25ms: src/web/index.html
    frontend TypeError: Cannot destructure property 'isLikelyComponentType' from null or undefined value
        at V0 (http://localhost:4200/_bun/client/index-00000000ac7e3555.js:24:2534)
        at reactRefreshAccept (http://localhost:4200/_bun/client/index-00000000ac7e3555.js:21:6090)
        at http://localhost:4200/_bun/client/index-00000000ac7e3555.js:8766:27
        at CY (http://localhost:4200/_bun/client/index-00000000ac7e3555.js:21:8973)
        at nY (http://localhost:4200/_bun/client/index-00000000ac7e3555.js:21:9285)
        (...more like this...)
        at m (http://localhost:4200/_bun/client/index-00000000ac7e3555.js:21:8773)
        at http://localhost:4200/_bun/client/index-00000000ac7e3555.js:24:6482
        at http://localhost:4200/_bun/client/index-00000000ac7e3555.js:24:6548
        from browser tab http://localhost:4200/
    ^C
      schematic git:(main)  bun upgrade --stable
    Downgrading from Bun 1.3.14-canary to Bun v1.3.14
    [2.02s] Upgraded.
    
    Welcome to Bun v1.3.14!
    
    What's new in Bun v1.3.14:
    
        https://bun.com/blog/release-notes/bun-v1.3.14
    
    Report any bugs:
    
        https://github.com/oven-sh/bun/issues
    
    Commit log:
    
        https://github.com/oven-sh/bun/compare/bun-v1.3.14...bun-v1.3.14
      schematic git:(main)  bun run main.ts serve
    Schematic Editor running at http://localhost:4200
    [browser] Version mismatch, hard-reloading
    Bundled page in 20ms: src/web/index.html
    
    # working fine as usual... ¯\_(ಠ_ಠ)_/¯

I mean "passes test suite" is one thing. And a good thing. But... "doesn't break any (or even, say 99.5%) of the apps deployed around the world that are built on bun" is a pretty radically different thing.

It's hard to feel like this is responsible behavior, but I will reserve judgement for now, and see how long they persist this "canary" phase.

If they extend it for a lengthy period, and even like, fix bugs on the Zig version and the Rust "canary" version, then... I would be mollified to a great extent, since it is so easy to switch between the Zig stable version and the Rust canary version.

As a pretty heavy user of Bun, I'm actually pretty psyched for it to switch to Rust... but given the abruptness and speed so far, I can't quite shake the "new AI dealer getting high on his own supply" vibe.

But I hope they enter an intensive phase of prioritizing any and all "canary" bugs, and come out on the other side with a better product, and an even faster rate of improvement (which has honestly been pretty wild already).

(Yes, of course, I will have my clanker file a bug report with repro... but that may take a few days.)

keeganpoppen 3 days ago |

i find it hilarious how desperate people are to cope that this can’t possibly work, must be horrible, etc. for all i know, it is. but let’s just see how well it works, rather than “no true scotsman” grouse about it. it is so sad. it reeks of “doth protest too much” energy. if it were so obvious that ai was insufficient to do the work, then i don’t think you’d have to circle the wagons about it. you could just confidently watch the market turn on the product and know the reason why. and all that would prove is just how special you all are that ai cannot replicate your genius. the reality is that foundation model makers have been dogfooding their own vibes for multiple years now, and it is clearly is good enough for _them_. but yeah, i’m sure that’s just a total fluke and they are all idiots. /eyeroll

JackSlateur 3 days ago | |

Last time I took the Time to see details about such crap, it was CCC.

Great advertisement, fails to compile a random C projet I have, waste of my time.

suck-my-spez 3 days ago |

What a disaster

the_black_hand 3 days ago |

I'm old. currently in npm dependency hell on my side project. wtf is bun and will switching to it save me?

culi 3 days ago | |

Unlikely. Not all npm packages are even compatible with Bun (tho 98% are).

Bun started off as an alternative runtime to Node (like Deno) but today is an everything-monster. It even has a built-in test-runner.

To be completely honest, if you're dealing with dependency hell in 2026 you might be misusing npm. Or you're trying to update a really old project

SuperV1234 3 days ago |

I'm bullish on LLM-assisted development but this is just a very stupid way of performing such a critical migration.

matt3210 3 days ago |

Now pull the branch and roll your own bun without license issues (using an ai) against their test suite.

the__alchemist 3 days ago |

Bun alert!

npn 3 days ago |

farewell, bun.

dmitrijbelikov 3 days ago |

Rust, Zig and TS went into a bun... /s

cybercatgurrl 3 days ago |

good, their time was wasted on trying to upstream into zig with their anachronistic values on LLMs

aizk 3 days ago |

I might not necessarily agree with the haste / stability of this, but I commend Jarred for pushing boundaries on what AI coding is capable of, can't deny that. 4 years ago this would've seemed like science fiction.

maipen 3 days ago |

HN overreacting again.

I trust Jarred to make the right decisions regarding bun, which seems to be his passion. Bun has always been amazing since i first tried it, it had some bugs along the way, which didn’t last long.

Anything bad that comes from this, will simply be fixed.

I hope more software does this and gets rid of their segmentation fault producing code, written in c++ and other unsafe languages

I can think of a few.

sensanaty 3 days ago | |

It has 10k unsafe blocks, pretty sure those segfaults are still gonna be there

dolmen 3 days ago | | |

Definitely. That's what a good translation is.

But then, agents can work on removing each unsafe one by one and this will bubble issues.