[Jarred]

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.

[tasuki]

You, nine days ago[0]:

> I work on Bun and this is my branch

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

Maybe... it wasn't such an overreaction?

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

[Tesl]

I'm really out the loop here so maybe you can help answer me a question - why is HN unhappy about this rewrite? why are people writing here almost as if they feel betrayed by Bun being rewritten from Zig into Rust?

I genuinely don't get it. I've been following this Bun stuff a bit but I don't understand where the HN sentiment is coming from.

[ku5h]

Because in the software world, especially before 2022, ownership and stability have been valued. People like using things that do not randomly start breaking more often after every new release, and if things break, there is a human who knows exactly why it broke and what's the best way to fix it. Businesses would not want their losses to be attributed to an AI rewriting an entire codebase. AI owns nothing, not even the bugs which it produces. I would not want my SaaS to have downtime because a JavaScript runtime it depends on decided that they had to market their LLM by rewriting years of code recklessly.

People are not betrayed by a rewrite. They are betrayed by an LLM rewriting with minimal supervision fasttracked to a merge within 9 days of commencement.

To the contrary I do not understand how we have become so insensitive towards stability since the LLM era. Why is unbreakable code no longer the goal but a truckload of generated code is.

[ForHackernews]

> Businesses would not want their losses to be attributed to an AI rewriting an entire codebase. AI owns nothing, not even the bugs which it produces. I would not want my SaaS to have downtime because a JavaScript runtime it depends on decided that they had to market their LLM by rewriting years of code recklessly.

I don't know how else to say this but "Tough Shit"? Businesses are building their entire enterprise on the volunteer work donated by the free software community (or given away for free by some other company solving its own problems).

If you don't want 'your' SaaS to have downtime based on somebody else's whims, then fucking pay for your own developers (or your own AI) to build your SaaS platform in house. That's what IBM did in the 1970s, and nothing except market pressure is stopping you from doing it today.

I'm sorry for the vulgarity but this entitled attitude of businesses toward FREE SOFTWARE GIVEN TO THEM FOR NO MONEY is infuriating. If the electric company decided to give your company free power on windy days, would you then get angry that they installed a new model of turbine?

[Capricorn2481]

You should place this energy with something like ripgrep, not a company with huge funding that actually depends on people using their product. Their whole thing is convincing you to use Bun over Node.

[ForHackernews]

so...don't be convinced? Use Node if you prefer Node's governance style. Or Deno?

If they "depend" on people using their product, then surely all their paying customers will be happy to pay them whatever it costs to maintain the Zig-version-Bun that matters so dearly to them. They will see the folly of this rewrite and follow the money back to Zig.

[self_awareness]

> Because in the software world, especially before 2022, ownership and stability have been valued.

Stability in JS ecosystem was never valued.

[Capricorn2481]

The context nobody is mentioning is this came shortly after Bun forked Zig in the name of optimization, but then a Zig maintainer came out and basically said they (Bun) don't know what they're doing, or else they would have known that wasn't an effective optimization.

It outwardly seemed like they forked Zig for a flashy headline, were called out, then immediately started moving to Rust. This, combined with being bought by Anthropic, and plugging vibe coding the whole way, just gives the impression of random and chaotic technical decisions, which is not what people want in software their business depends on.

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

[vickychijwani]

The unhappiness is primarily stemming from Bun’s ownership by Anthropic - HN sees this as Anthropic using an OSS project for reckless marketing stunts.

For the record I don’t believe it’s a stunt, it’s ridiculous to me - everyone’s just seeing what they want to see out of sheer hate for anything Anthropic does.

In any case if the rewrite is really as reckless as many in this thread claim, we will see Bun collapse in on itself with a 1M LOC codebase the core team doesn’t understand, or rollback to Zig. So we don’t need to have a flamewar over it, time will answer the question.

[itishappy]

My read is it's less the rewrite and more the messaging around the rewrite. Nine days between "you're over-reacting" and merge is surprising, to say the least. Sure will be interesting to see that blog post!

[noelsusman]

Vibe coding a Rust rewrite of a widely used tool is basically catnip for the HN crowd.

[zarzavat]

Not if you use that tool, then it's just scary.

[petcat]

I would think the Zig implementation with 500+ issues on Bun's GitHub tracker mentioning "segfault" would be even scarier.

[sqquima]

My read. If the code has a comprehensive feature test suite, a performance test suite (how long a function takes), and a linter with readability guidelines (e.g. cyclomatic complexity; no code duplication), and the LLM rewrite passes all three, then it should be fine. But I think that in the real world only the first one (functional tests) exists.

[jorisw]

Maybe Jarred can fill in here

[taejavu]

My read is that it just seems a bit reckless doing a full rewrite so quickly.

[sigmar]

posting my read (since it differs so much from the others')- there's a 'holy war' being waged by people that think LLMs shouldn't do full rewrites of software. There are various reasons people think this (think LLMs are parrots that make slop and are incapable of writing good code, have environmental concerns, or are angry that software licenses can be circumvented). I call it a 'holy war' because I think most see our current trajectory as a bit inevitable and have a strong urge to proselytize their views and chide maintainers that use LLMs in ways they don't like.

Very similar angry comments happened with the discussions of the Chardet rewrite, next.js/vinext, and JSONata/gnata if you want to look at this in context.

[embedding-shape]

You're not alone in voicing this, another (now dead) comment did it earlier too with a bit more of an emotional response (https://news.ycombinator.com/item?id=48134229).

Still, do you folks never do something to see how you feel about something, then chose to go one way or another? I'm not sure why it's so hard to see that it was an overreaction at the time, because it was an experiment, then at one point it stopped being an experiment and now they've chosen to actually run with it?

Is this not a common occurrence for other people? Personally I change my mind all the time, especially based on new evidence, which usually experiments like this surface, I'm not sure I understand the whole "You said X some days ago" outrage that seems to cause people's reaction here.

[tasuki]

Yes sure it's ok to change your mind. But don't you think the people Jarred accused of "overreacting" in retrospect didn't?

[embedding-shape]

No, what we knew then is still what was known then. Today is different, and seemingly they've committed to the rewrite, so now it makes sense that people have strong feelings about it, as it's no longer just an experiment.

[grayhatter]

> so now it makes sense that people have strong feelings about it, as it's no longer just an experiment.

It also makes sense to have strong feelings when you're able to pattern match well enough to predict something will happen despite others trying to convince you that your predictions are incorrect.

It's not overreacting when correctly predicting the future, just because others couldn't. In the same vein, the idea that "everyone out to get you" is not called paranoia when there are people actually out to get you. That's better called being observant.

Some of those who predicted correctly might also have overreacted, but I believe that the majority understood that to be a blanket statement about prediction as a whole vs any specific individual reaction.

[tasuki]

Maybe the people who "were overreacting" just happened to have more foresight than you and me? Perhaps they saw where this was heading, and that led to their "overreaction"?

[embedding-shape]

In what way? Foresight about what? It was an experiment before, regardless of people's reaction at the time doesn't make it less of an experiment back then. I feel like I'm misunderstanding this entire conversation right now.

[serial_dev]

“Nobody could have seen this coming…”?

Well apparently a lot of people did. Maybe Jarred didn’t, maybe you didn’t, but most people correctly predicted what was coming.

[embedding-shape]

See what coming?! I really don't understand what's going on here. Correctly predicted what, that Bun was being rewritten into Rust? I'm not sure anyone doubted that, all the work they did was public???

What on earth is going on here?

[hombre_fatal]

The top comment at that link points out how many of the sibling comments are delirious and emotional, kneejerk responding to the news rather than giving any sort of sober analysis.

That people were overreacting with emotional meltdowns (common in AI-related threads) is perfectly compatible with the branch making enough progress to get merged.

[wiseowise]

Anyone who disagrees with me is having an emotional meltdown and obviously they're delirious AI-haters.

[Muromec]

I'm not in a cult, you are in a cult and delusional!

[BoorishBears]

This seems dishonest.

I'm reading through the top comments next to his and don't see that. You can always find delirious and emotional takes, but those didn't dominate the discussion

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

> [...] Time will tell how this will turn out. Would be nice if the Bun maintainers could give some clarification about what they’re doing here, and why they’re doing this.

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

Compares this to Go runtime's C to Go migration

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

Link to Github diff view

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

> I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.

[weird-eye-issue]

Who cares? Go see a therapist

[wiseowise]

It's a high profile open source project. While Bun/Jarred don't owe anything to anyone, nobody should be surprised when decisions like these result in strong backlash.

Imagine if Guido or Linus said a couple of days ago that they're just experimenting and then submitted and merged complete machine-assisted rewrite of CPython or Linux in Rust.

[buu700]

This actually happened to me a couple months ago. Started a Rust rewrite of a project as an experiment, then a few weeks later it was presented to the team and promoted to mainline.

Although in that case the language change was almost incidental — the rewrite was very much not a straight 1:1 port, but more of a substantive architectural overhaul and longstanding tech debt cleanup; Rust was just one of many tools and design decisions that helped get the best possible end result. There were also various reasons it made sense to attempt a rewrite within that particular window of time.

The upshot is we've ended up with a substantially stronger QA posture, a much higher-quality and more maintainable codebase, and an extremely positive audit report by a group that was brought in to review the project. There were some early kinks to work out, but the longer we've lived in this version of code the more it's proven itself to be a stronger foundation than its predecessor.

Of course, Bun is its own thing and all circumstances are unique. I have no idea how that rewrite was approached, whether it was the right decision, or how it will ultimately prove itself. Just saying the shift from "experiment" to "official new direction" is normal and credible, and that I'd give it some time to see how it handles contact with reality before passing judgement. If it's truly a disaster, nothing's stopping them from reversing course and backporting any new changes to the old Zig codebase.

[imenani]

The author discussed this here four days ago

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

[dannersy]

I was down voted pretty hard for calling this comment out. I would say I'm surprised but honestly? Completely predictable.

[camdenreslink]

Yea, what the heck.

[andrepd]

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

How can you possibly verify this, if a 1M line patch was written over 7 days? It's at best a hunch (vibes?), and at worst a lie.

[cwyers]

Because it passes the existing test suite? And he knows what's in the test suite?

[thearrow]

The test suite explicitly verifies the architecture and the data structures used? Depends on the suite, I suppose.

[pulsartwin]

Looking forward to the blog post. Do you plan to run both the Zig and Rust binaries side-by-side across a wide range of real applications (potentially shadowing in production) to weed out bugs?

[arm32]

That's way too smart, safe and sensible.

[aapoalas]

They have a PR (~~closed by GitHub bot as AI slop, ironically~~ this was wrong info, it was apparently closed by Jarred himself as it missed a conversion or some 20 Zig files to Rust) to remove the Zig code.

I guess the answer is "no".

[janice1999]

I'm curious how much this would cost a paying customer. Can you please give us an estimate?

[nzoschke]

Great question and I'd love the answer.

I bet the answer is industry changing even if the token cost is high.

This work was impossibly expensive in terms of people hours and time before. Architectural planning, engineering alignment and politics, phased engineering that gets interrupted by changing priorities.

That it's possible to do R&D, the port, and get 99.X test passing in less than 2 weeks is so much more efficient for the humans.

[dlopes7]

I bet the blog post will make no mention of pressure from anthropic to do this and instead will celebrate the fact that “it passes all tests”, of course omitting how many tests were modified to forcibly pass

[giancarlostoro]

Do you have any proof Anthropic pushed for this? Because the author has been clear this was an experiment they wanted to test out on their own, only when it seemed to be in a working state did they consider, okay maybe this might work for us.

[shimman]

Does it take a phd in psychoanalysis to not see that the company that has been marketing the fuck out of lame publicity stunts, to not take advantage of another publicity stunt? Good lord, no wonder the public hates tech workers.

[giancarlostoro]

I refuse to blindly hate something because someone tells me to with no evidence, if you want to hate me for that, so be it, that sounds like a personal problem.

[kenloef]

Show me the incentive and I'll show you the outcome.

[giancarlostoro]

Anthropic is unable to contribute to Zig due to new AI policy, Bun has to maintain a fork of Zig, the lead developer decided "what if I try Rust? can the model do this for me in a meaningful way?" is that so hard to believe? I've done it with Claude before this story was blown out of proportion. It's basically one of the strengths of language models. If you frequent any reverse engineering communities, a lot of breakthroughs are coming from people having Claude disassemble things and translate it to either specs of raw source files in a new language, to the point that it compiles.

So from the context of someone who has never done this with Claude, or GPT, or any other model, I guess I could see how this would smell like a marketing stunt, but Anthropic already has marketing videos for this sort of thing on their YouTube as of last year. They have a video of Claude going through legacy COBOL code and modernizing it. Whereas all of you guys are giving me "trust me bro" as your only evidence.

[dlopes7]

I don’t have proof, but I can offer you that dexter suspicious meme instead

[awwaiid]

Was there pressure to do this, or freedom to do this? If I had an unlimited token budget I'd probably try all sorts of crazy things. Also you (one) can read the tests and see that they weren't modified to forcibly pass.

[halifaxbeard]

Any plans to issue a CVE for this HTTP request smuggling attack vector fixed in the latest bun release?

https://github.com/oven-sh/bun/issues/29732

[classicposter]

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

Surprisingly, they appear to have not disclosed any vulnerabilities whatsoever. It's likely there have been numerous vulnerabilities in the past, but they are all being ignored.

https://x.com/DavidSherret/status/2031432509301428644

[halifaxbeard]

This is really poor form given that Anthropic is going around getting all kinds of public goodwill for finding CVEs in other people’s products.

[shimman]

Yeah! Why would the company that stands to make themselves look better in front of an IPO do such a thing?! Next thing you're going to tell me was that this whole rewrite was another marketing ploy to help potentially turn themselves in multi-millionaires!

[dwattttt]

Yes, it is helpful for a company to be very clear that in a choice between the safety and integrity of their customers, and profit, they are choosing profit.

[grayhatter]

maybe you should ask on the issue directly?

[calmoo]

Will this likely fix stability issues in the Bun Workers API? https://bun.com/docs/runtime/workers

[randypewick]

Did you (or will you) implement some kind of e2e (fuzzy?) testing comparing the two binaries? Do you have particular plans regarding the release of this (for ex to not break users workflows or things like that)?

[underdeserver]

Is writing the blog post taking longer than the rewrite

[Jarred]

almost

[cyanydeez]

So a question you should answer: Couldn't you just train the super SOTA model on fixing those issues instead of porting it?

[eddiewithzato]

I can hope this will lead to little to no memory issues in using bun as a web server

[embedding-shape]

I'd be surprised if they could eliminate memory issues completely, especially considering the amount of `unsafe` the codebase seems to contain.

    git rev-parse HEAD && ag "unsafe" src | wc -l
    19d8ade2c6c1f0eeae50bd9d7f2a4bf4a2551557
    14865

[e12e]

On the other hand - now it should be possible to tackle some of those one by one?

[embedding-shape]

Oh yes, I don't doubt they'd eventually be able to seriously reduce that number, probably to a handful of places. I don't doubt the strategy employed here, rewriting it keeping it similar, then slowly change it. I do still doubt they'd be able to completely eliminate memory issues in the end regardless.

[Narishma]

Doesn't that count anything that has 'unsafe' in it, not just the keyword?

[embedding-shape]

It does, see the sibling comment made about an hour before yours, fixing that issue has marginal difference.

[davidghowell]

That's picking up all the "bunsafety" references in there :P

[embedding-shape]

When I read what you wrote, I was like "of course, duh, I'm stupid" but running `ag "unsafe" src | grep -i "bunsafety"` it doesn't seem to be the case actually, I see zero bunsafety mentions from it.

However, `ag unsafe` does over-count anyways, just in a different way, matching stuff like SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION and _unsafe_ptr_do_not_use and others.

Better command with same previous commit, `ag -w unsafe src | wc -l`, reports 13914 "unsafe" usages now, slightly better but pretty awful still.

[logicprog]

My understanding is that that's because they were trying to do a structurally homologous port from Zig to Rust, precisely to keep their mental model and not change "too much" at once, and then they plan to refactor to make it safe Rust later.

[rpearl]

it's clear that as of the time of this merge, no human has read any appreciable fraction of current mainline bun, so it's not particularly clear how much of a "mental model" exists anymore.

[dolmen]

Does that mean that from now your coding agents working on the Bun codebase are themselves running on that rust-Bun runtime?