Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How is the Bun rewrite in Rust going?

lockwood.dev

Post reply on HN
Print view View original

141–150 of 412 posts

Re: How is the Bun rewrite in Rust going?

#141

Post by windexh8er »

klausa wrote: post #84
flohofwoe wrote: post #63

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.

Look, I understand being skeptical of the whole process; the discourse about this has been extremely tiring. But at some point if “moving one of the biggest actively maintained and used codebases to it without anyone noticing” is dismissed as “it doesn’t mean all that much”, then we’ve lost the plot a little bit somewhere.

This is akin to saying "we replaced the tires on the car and the average user didn't notice". If the entire car was replaced, then maybe we get a bit more excited.

However if "replacing small sections of code" is heralded as "the most amazing achievement in software development" then we've all lost the plot a little bit somewhere.

It makes sense both ways, no?

The reality is, of course, most people aren't going to notice. If the functionality and performance is 1:1 why would they? Is it impressive? A bit, but not how you're positioning it. People seem to forget LLMs are good at what they've learned from training data. And the LLM is good at compressing time. The only notable thing about these types of marketing spins is that a rewrite was accomplished in a small time frame that was hard to pull off before LLMs. The actual act of the move is less so.

Did the codebase improve? Is it more performant? I've seen nothing to really stake those claims with any objectiveness. Lastly: what was gained?

Re: How is the Bun rewrite in Rust going?

#142

Post by IsTom »

Aurornis wrote: post #133
muglug wrote: post #7

This post doesn’t make sense. It was rewritten in Rust. The rewrite itself is complete (no more Zig). Various people have claimed that Bun in Zig had a lot of tech debt. If they’re to be believed, it seems natural to assume the rewrite does, too. Perhaps all this activity is paying down some of that debt.

> Various people have claimed that Bun in Zig had a lot of tech debt. If they’re to be believed, This is one of the funnier takes on the rewrite. Bun was held up as a flagship Zig project for years. Then they chose to rewrite in Rust and everyone up to the Zig author has suddenly switched to claiming that Bun was terrible code all along.

If what they're claiming is true then what were they supposed to do? Go "Hey guys, it's the biggest project in Zig and it sucks, don't look at it"? Not exactly a good PR move.

Re: How is the Bun rewrite in Rust going?

#143

Post by a2800276 »

flohofwoe wrote: post #63
usef- wrote: post #26

Earlier quoted context omitted.

They also have made a release, in a sense, since they moved all Claude code users to it a month ago. (And apparently no one noticed). I think they're taking things "gradually" as they are under a lot of scrutiny and no rush for full release.

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.

You didn't seriously expect Anthropic to seriously maintain bun as a general purpose plattform? It's clearly the Claude Code Runtime that you're graciously allowed to continue to use for your toy projects.

Re: How is the Bun rewrite in Rust going?

#145

Post by msdz »

jdiff wrote: post #127
jFriedensreich wrote: post #67

Earlier quoted context omitted.

because their js code is so bad and slow that they need the bun performance hacks and optimisations.

Do these hacks make bun less secure than other runtimes? I find it a little hard to believe you can get much more robust and performant than V8 or SpiderMonkey without cutting some corners that notably went uncut by either for all these years.

Bun uses JavaScriptCore, which is Safari’s JS engine, for the actual interpreter portion of its runtime.

Which makes the parent comment’s “Bun performance hacks and optimizations” sound a little far-fetched, at least in this scenario I don’t think that’s gonna be the deciding factor. Their vendored JSC is also not touched by this port-rewrite at all whatsoever (still Cpp), so I’m not sure if it’s even possible to hack-improve all that much there.

Re: How is the Bun rewrite in Rust going?

#147

Post by skeledrew »

flohofwoe wrote: post #73
irishcoffee wrote: post #50

Earlier quoted context omitted.

So "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?' How odd. Lot of mental gymnastics going on there.

The Bun author himself writes that the port is not idiomatic Rust: Do the rewrite that looks like we transpiled our Zig code to Rust. We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships. (from: https://bun.com/blog/bun-in-rust ) The original version of Bun was already a line-by-line (manual) port of esbuild from Go to Zig (also mentioned in this post), so the Zig…

> That doesn't inspire much confidence in the LLM-translated Rust version tbh.

And yet Claude Code, which is the primary consumer, continues to chug away without any issue (that I, as a fairly heavy user, have encountered).

Re: How is the Bun rewrite in Rust going?

#148

Post by Jarred »

Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall.

In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likely next Tuesday we’ll do the release of 1.4.

Re: How is the Bun rewrite in Rust going?

#149

Post by williamdclt »

irishcoffee wrote: post #50
vessenes wrote: post #46

Earlier quoted context omitted.

Presumably lots of stuff wrapped in 'unsafe'. I'm not a rust guy or a rust fan, and the last time I wrote something with Rust was like 7 years ago, but to my memory, because of how Rust manages mutability there are many access patterns that are Rust-specific; idiomatic Rust is going to use this patterns but they would be unlikely to show up in a language with a different type system / borrow checker / etc. etc.

So "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?' How odd. Lot of mental gymnastics going on there.

> "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?'

that is indeed a roughly accurate definition of what "unidiomatic" means

Re: How is the Bun rewrite in Rust going?

#150

Post by skeledrew »

TazeTSchnitzel wrote: post #69
irishcoffee wrote: post #38

Earlier quoted context omitted.

> produced idiomatic rust I keep seeing this. What is "un-idiomatic" rust?

Rust contains the ability to do everything that C can, if you use `unsafe`. And a file-by-file rewrite in Rust from another language usually involves keeping the ABI and API between files very C-like (and unsafe). In practice this means that the result of a first pass this way has all the memory safety of C code, but with worse readability because Rust makes unsafe things less ergonomic. To actually get the safety be…

> one that an unsupervised LLM rewrite is probably not even going to attempt.

Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).

Post reply on HN