There’s no way they can know that for sure. A change of this magnitude cannot go from experiment to success in such a short time frame. Even if all the code were 100% correct, you can’t call it a success until it’s battle tested in real world scenarios for a while, and that is impossible without time. Same way you can’t cook properly by throwing food into a vulcano. It’s not just about the temperature.

Either the “experiment” claim was a lie or they are being irresponsible.

No, you are perfectly normal.

The people who in one week decided to replace the whole codebase for a widely used tool with code no human has seen are the crazy ones.

There’s probably loads(?) of observable behaviors that people rely on, consciously or not. Even _if_ the new thing is 100% spec compliant, it might still be breaking or otherwise problematic for heavy users.

That said, I’d love to be proven wrong. I use Bun from time to time on small stuff and I enjoy it, so I wish them well (:

It takes a lot of rigorous testing automated and manual and by community before such changes are cosnidered permanent.

One does not simply YOLO a full langugae rewrite without user feedback. it is insane.

Not at all. Supporting a methodical conversion to Rust seems reasonable. How could you have predicted they'd shotgun it?

Having said that, after looking at some of the test changes, they seem to be minor things, like changing timeouts, not changing the actual intended semantics of the tests. But it's too much code to review everything, so I might be completely wrong about that, and in real-world usage, even minor changes like these will cause issues.

I'm happy it's not a project I'm depending on, but a large enough project had to try this at some point so that we all can learn from how it goes.

I think this is why Antropic bought bun, so that they can sell big code translation as a feature for all the banks with COBOL code that they want to get rid of for a long time.

Still, those banks / enterprises won't appreciate the number of unit test changes.

And I agree with another comment that Codex xhigh is much better for these kinds of tasks, but still hard on this kind of scale.

The MR is right there, linked at the top of this page. You can check who is telling the truth.

That said, I don't know how anyone is actually claiming to have done that. All day, the size of the MR makes the diff take too long to load and GitHub dies. I'll have to pull it later to check myself.

Strange test though either way.

It's too bad you haven't structured the commits and pull requests a bit differently so that it's easier to review the exact changes, but I hope it goes well.

For example doing the test refactorings in a first pull request, and using something like test.xfail that is first fails then after the merge succeeds (but the test code itself doesn't change).

Also I have seen some tests getting stricter, which is again not a problem, but separating to a different pull request would have improved the reviewability significantly for a runtime that many people and companies depend on.

I'm sorry you were downvoted by HN and your comment got ,,dead'', that's not the way to review things.

What is "most of that "?

Why did you feel the need to produce so much detail about a single category of tests?

/s

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

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?

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.

Reengineering a well-used open source project… that's proper hubris territory, if you do it poorly enough.

It's outside their "zone of absolute terror", to put it in anime references. Any argument against them while inside their domain is countered by their apparent success; as much as it pains me, the shit code did deliver enough. Not so when they step outside that domain, Bun was delivering before.

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

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

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.

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

That's not entirely true. At a certain scale, some languages start becoming increasingly more of a factor. Memory issues in C/C++ codebases, for example. This is pretty well established at this point, which is why there's a push to move away from memory-unsafe languages. Which likely would include Zig, for better or worse.

So now imagine your company and project -- written in Zig -- has just been acquired by the world's biggest/second-biggest AI company.

That company's most successful and popular tool is running on your platform that is written Zig.

And Zig maintainers want nothing to do with you.

What kind of pressures, real or imagined, do you think that puts on the developers of Bun?

Honestly, from what I've seen from a distance, actual rigorous software engineering doesn't happen at Anthropic. From what we saw of the Claude Code source, the reliability issues over the last few months, and now this. It's just a bunch of people getting high on their own supply falling all over each other. Quality issues galore and a delirious frenzy.

FWIW I don't think it's intrinsic to AI. Codex is very well written (in Rust, BTW), fast, and consistent.

> Code origin was not even a factor [0]

> AI is entirely besides the point here. The changes in this Zig fork are not desirable to upstream for several reasons. [1]

So my view here is that besides AI policies to filter low value contributions and "contributor poker" [2] to attract contributors vs just contributions, a well thought of genious implementation aligned with the Zig roadmap instead of the "hacky implementation for a flashy headline" [1] would have made the cut.

But then again this entertaining drama will sadly get deprecated by mid 2027 as the datacenters will be churning out their own opusrust and clankzig.

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

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

[2] https://kristoff.it/blog/contributor-poker-and-ai/

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

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

I guess the answer is "no".

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.

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

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.

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.

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

"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!"

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.

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.

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.

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

Merging it so quickly only odd if you're planning on retaining current community.

It's not like it was merged and shipped to every single stable distro overnight. That's how things get tested.

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.

:p

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

2. Turn into idiomatic rust.

It also looks like the top 2 maintainers are currently actively working on getting the amount of unsafe down and it's going down quickly.

Bun needs to interact with FFI code. This gets wrapped in unsafe blocks.

There are many places where a JavaScript interpreter and library would need to make unsafe calls and operations.

It doesn't literally mean the code is unsafe. It means the code contained within is not something that can be checked by the compiler, so the writer takes responsibility for it.

There are many low-level data munging and other benign operations that a human can demonstrate are safe, but need to be wrapped in safe because they do things outside of what the compiler can check.

To win a news cycle.

For the forseeable future, the AI market competition is not about which product can provide the most valuable utility to users. It's about which product can be holding the protective aura of social media and investment zeitgeist while competitors buckle under the strain from unfulfilled hype and over-leveraging.

Utility, engineering, efficiency... these are all menial details for the winners to reluctantly iron out in 2035.

But given the whole "let AI rewrite this for me" stunt nature of this project that was not going to happen because that would require well, actual thinking and a re-design. So now you have Zig disguised as Rust and a line-by-line port because the semantics of idiomatic Rust don't map on the semantics of Zig.

https://github.com/ityonemo/clr

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?

Even if it's mostly accidental, and the code is overengineered slop (which it is), the system being able to decompose a problem and deliver something is impressive in terms of stability: it wasn't sucked into rewriting everything from scratch every time it would run into issues, it didn't have infinite subagent recursion with a one-agent-per-line type workflow, etc.

    +1 (009) 257-4024

123456

1234567

12345678

So if the text includes a phone number, email address, flight number, package tracking number, street address or other pattern in the data it is underlined and allows you to perform one or more actions.

The patterns it looks for and actions it takes are extensible by developers.

If you don't care for it, you can turn it off.

I don't know enough about what Bun does... But Rust is so insanely complicated, it's hard for me to wrap my head around how Bun is equally complictated.

"Bun is a batteries-included JavaScript & CSS transpiler (parser), minifier, bundler, npm-like package manager, Jest-like test runner, as well as runtime APIs like a builtin Postgres, MySQL and Redis client. This is naturally a ton of code."

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

This is the 'world class' engineering that Jarred claims he can't hire Americans to do, by the way https://x.com/jarredsumner/status/1969751721737077247. This company is parasitic to its literal (javascript) core.

"If you can't trust your test suite to catch a hardware floating point arithmetic bug, you shouldn't trust it at all."

"If you can't trust your test suite to catch a JVM bug, you shouldn't trust it at all."

"If you can't trust your test suite to catch a recurring memory error, you shouldn't trust it at all."

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.

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

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.

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.

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

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

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