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

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

91–100 of 560 posts

Re: Rewriting Bun in Rust

#91

Post by YuechenLi »

benced wrote: post #35
YuechenLi wrote: post #29

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows. People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of m…

Not a compiler expert - shouldn't language verbosity and binary size be, at best, very loosely related?

Fair point, I phrased that too broadly, and you are right about the loose correlation.

What I was gesturing at, badly, was more that Zig’s low-abstraction / explicit-by-default syntax tends to have you write more boilerplate-y code in general that are more annoying to write and maintain, while not buying you enough over a language with better tooling and ecosystem and compiler optimization like Rust.

Re: Rewriting Bun in Rust

#92

Post by gpm »

geon wrote: post #23
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

Wouldn't the same improvements have been made in zig if they instructed the agents to improve instead of rewrite?

Maybe they'd get the same numeric improvements and bug fixes today (or maybe not, or maybe they'd get even more since the LLM isn't spending time rewriting correct code).

But they wouldn't get a change to the structural issues that created the issues in the first place. They'd end up "ke[eping] fixing these kinds of bugs one-off in perpetuity".

Re: Rewriting Bun in Rust

#93

Post by simonw »

Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

I don't think it's care to categorize this as "a naive rewrite away from [Zig]" - Jarred has been immersed in this project for five years, got to benefit from everything he learned along the way and spent $165,000 of tokens on the most advanced coding LLM anyone has access to.

I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.

Re: Rewriting Bun in Rust

#94

Post by ameliaquining »

Buttons840 wrote: post #78

I've always felt [0] the people who created Bun had, as their first and foremost goal, a desire to use Zig--and that's great, I like Zig, I like when people build things their own way. However, I've been skeptical of using Bun, because I want a project whose first and foremost goal is to build good tools that achieve the objectives of the project. It reminds me of asking game developers: Do you want to build a game ,…

So does that mean the rewrite made you less skeptical?

Re: Rewriting Bun in Rust

#95

Post by daishi55 »

silver_silver wrote: post #56
lifthrasiir wrote: post #26

Earlier quoted context omitted.

The article explicitly mentions the maintainability as a foremost concern.

People say a lot of things, especially when they have a vested interest in a positive outcome. Bun has been fully vibe coded into another language. There’s no way in hell it’s maintainable. Go read any analysis of the Claude Code leak for proof.

> There’s no way in hell it’s maintainable

This is not an assertion you are qualified to make

> Go read any analysis of the Claude Code leak for proof

You seem to be implying that Claude code is unmaintainable. Yet they appear to be maintaining it just fine. Did I misunderstand your implication?

Re: Rewriting Bun in Rust

#96

Post by nzoschke »

> Historically, rewrites are a terrible idea.

This changed for me over the last 5 years.

The first scenario was joining a company where a software product barely worked. We did the traditional incremental refactoring / rewriting, but eventually learned how rotten the core was that rewriting from first principles was the best path forward.

The lesson learned here is that the conventional wisdom probably only applies to rewriting complex but working systems.

Then multiple scenarios in the agentic coding age. Between day jobs and hobbies I've reproduced major chunks of complicated software like Salesforce, Gmail, Pioneer Rekordbox with very lean teams.

Much like the blog post, the trick is to get an excellent verification loop with a compiler, linter, and test harness / test suite around the core behaviors.

It's feeling more and more that designing and implementing comprehensive test harnesses is the real work, once you have that let the LLM cook.

Re: Rewriting Bun in Rust

#97

Post by erichocean »

fps-hero wrote: post #86
himata4113 wrote: post #75

They didn't mention the cost of this. Assuming mythos was somewhat involved I'd extrapolate this as: 128 x20 max accounts needed which comes at $25.6k or over 75k in api costs. For 75k you can hire a team of engineers that would produce a better result with sematic conversion and other tricks used in porting from language A to language B at the cost of maybe taking 1 month instead of 10 days. I will be a lot more exc…

> Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would've taken 3 engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The re…

Even at $165K, it's worth it to have a better base to build on top of—especially since it didn't take a year's worth of time for three programmers.

Re: Rewriting Bun in Rust

#98

Post by frollogaston »

silver_silver wrote: post #81
lifthrasiir wrote: post #64

Earlier quoted context omitted.

Claude Code is entirely vibe-coded for a long time. Bun isn't. You go read and compare the actual Bun code; it reads reasonably well [1]. [1] For example, as a random sample, https://github.com/oven-sh/bun/blob/bun-v1.3.14/src/css/medi... -> https://github.com/oven-sh/bun/blob/4924862cffbf671792d47c92...

Sure, reasonably well at first glance, but to quote the article: > I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days. > Excluding comments, Bun is 535,496 lines of Zig. > How do you review a PR with +1 million lines added? How do you start to build the confidence needed to responsibly merge large quantities of LLM-authored code? A language-independent te…

Doesn't look like vibecoding to me. It does look like a Claude ad, but they do have a vested interest in not screwing up Bun now that they own it.

Re: Rewriting Bun in Rust

#99

Post by [deleted] »

benced wrote: post #40
dfabulich wrote: post #27

This blog post further undermines my trust in Jarred. He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues." But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719 Observers could see this coming from a mile aw…

> We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. God forbid an engineer express uncertainty.

[deleted]

Re: Rewriting Bun in Rust

#100

Post by frollogaston »

"I used a pre-release version of Claude Fable 5 for much of the Rust rewrite."

It'd be interesting if Anthropic became a general software company just because they have access to models that aren't yet released, possibly export-banned.

Post reply on HN