Live data from Hacker News

How is the Bun rewrite in Rust going?

lockwood.dev

281–290 of 412 posts

Re: How is the Bun rewrite in Rust going?

#281

Earlier quoted context omitted.

> The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem. This seems self-contradictory. If it's just a translation, doesn't that mean it remains fully compatible with that wider ecosystem? All the existing APIs retain identical behavior given the preexisting comprehensive test suite that had to go 100% green after all.

> This seems self-contradictory. It's not. Passing an existing test suite just moves the optimistic lower bound to incidental compatibility, it doesn't move it to intentional - "regard" implies you gave it thought. Plus, it's not just about code: it's also about giving the ecosystem a migration path. Dumping 500k LOC on people and discontinuing development of the zig version effective immediately (there hasn't been a…

That "incidental compatibility" point is a good place to start. Unless there are serious gaps in the test suite, one can have high confidence that there's no regression from the pre-fork version in documented behavior.

What kind of migration path beyond 0 regression do you think is needed? And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? And what kind of release are you expecting when the team is working to fully migrate to the port (so far it's still marked canary)? If someone's using an untested (ie. very likely unpublished) API, well it sucks to be them but they should know the risks.

And again the self-contradictory argumentation. If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless. No ecosystem worth giving a migration path and nobody's N-API module breaking because of a regression, right?

Re: How is the Bun rewrite in Rust going?

#282

Many repeat the point of “$165k is cheaper than team of multiple engineers working on the rewrite for a year”, which I think is flawed — the team of engineers would have produced idiomatic rust, and it would take probably 100k+ of tokens more to make the bun in rust idiomatic rust.

Would they have, in a year? The general plan of attack would likely still be the same: rewrite it in rust while keeping the structure as similar as possible, no matter how unidiomatic, then adjusting the design to make it more idiomatic to rust. Doing both at once is much harder.

> Doing both at once is much harder.

I think with sequential approach (translate -> make idiomatic) it is easier. However, I am not sure that monetary difference is going to be as stark as $165k vs 3 engineers/year. Especially, if you consider that no one knows that is what in the code at the end.

Sure, you can argue that now it doesn’t matter — agents and all that, but I am not so sure.

Re: How is the Bun rewrite in Rust going?

#283

At what point should I trust projects like this? I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code. So I'm not sure I trust it just because tests pass. I also think that tests do not and cannot check everything. I also don't trust it just because it compiles in Rust. The Rust compiler does not check everything. So at what point do projects like this cross from "unt…

> I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code.

That's very easy to prevent. Don't let them edit the tests! Run the test suite against a reserved copy.

Re: How is the Bun rewrite in Rust going?

#284

I'm not sure Anthropic even cares about "releasing" the next version. The rust one has been in use in Claude Code for more than a month now, used by millions of people, and that's as far as they probably really worry about it. They bought Bun for Claude Code and I doubt the open source project matters to them otherwise.

Why wouldn't they? Bun is a major part of the web ecosystem, having it developed by them via AI, sounds like a gigantic pr win.

It’s not. Node is part of the web ecosystem. Bun was a way to upsell paas

Re: How is the Bun rewrite in Rust going?

#286
The Rust compiler suffers from a number of crash bugs and nondeterminism, and they won't accept AI diagnoses or fixes, so Rust has become an unreliable partner for software development.

If you're going to do serious development with Rust, I suggest forking the compiler. Upstream your fixes to a fork which takes AI contributions, or fork your own. Or keep all of your improvements private, that works just fine.

Re: How is the Bun rewrite in Rust going?

#287

Earlier quoted context omitted.

I think they meant “released and available for use” rather than just out in the wild.

It is available for use: `bun upgrade --canary`

it doesn't imply that lot legacy apps won't crash in prod when it will be actually released. Cool that some complex app is working but is nothing proving that everything will be fine when everyone will try to upgrade.

Re: How is the Bun rewrite in Rust going?

#288
post #121

Earlier quoted context omitted.

Claude Code most likely only uses a tiny fraction of Bun/Node features, so Claude Code switching to the Rust rewrite doesn't mean all that much.

I'll bite. Claude code interacts with many system processes, files, etc, as well as external APIs. Processes audio via built in dictation. Manages a bunch of nasty auth. Etc etc. What are the categories of features that wouldn't be exercised by this class of software?

This is probably a stupid question - as I’m totally unfamiliar with how interpreters call into system APIs - but would those calls use the bun runtime or the JavaScript Core engine the bun runtime wraps?

Re: How is the Bun rewrite in Rust going?

#289
post #283

At what point should I trust projects like this? I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code. So I'm not sure I trust it just because tests pass. I also think that tests do not and cannot check everything. I also don't trust it just because it compiles in Rust. The Rust compiler does not check everything. So at what point do projects like this cross from "unt…

> I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code. That's very easy to prevent. Don't let them edit the tests! Run the test suite against a reserved copy.

That makes sense to me as a tactic to prevent that problem.

But the article talks about how so much code was written so fast. Seems to me that to create that much code that fast you have to have AI produce both the code and the tests.

So I am not sure in this project if the AI can edit the tests or not. I assume that because this is Anthropic the AI is doing as much as possible, which would include editing tests.

Re: How is the Bun rewrite in Rust going?

#290
I don't quite understand the focus on the token cost of this rewrite. Obviously, we should examine if this rewrite is good, effective, good for the product etc., but the token cost seems ... not important?

The marketing value of this to Anthropic (if Anthropic even cares, this might just be the Bun team selling past the close) is to show that such a rewrite is possible and delivers engineering value. If exactly this project is $800K today, it'll be $200K and then $80K soon, so it's not so important to the story that it's cheap, just that a big "cool" rewrite is possible, and delivers velocity to the buisness.

Post reply on HN