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

81–90 of 560 posts

Re: Rewriting Bun in Rust

#81

Post by silver_silver »

lifthrasiir wrote: post #64
silver_silver wrote: post #56

Earlier quoted context omitted.

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.

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 test suite with a million assertions, adversarial code review and when something does go wrong, fixing the process that generates the code instead of hand-fixing the code.

That’s vibe coding. This blog post is an ad for Claude, nothing more.

Re: Rewriting Bun in Rust

#82

Post by talloaktrees »

lifthrasiir wrote: post #30
theLiminator wrote: post #28

That's the power of a strong test suite. LLMs excel when you have verifiable rewards. I imagine we'll get a lot more rewritten in rust projects in the future. Rust is also an ideal target for such rewrites as it offers a lot of verification (via its type system) and is low overhead with zero-gc. There's less and less reason to use GC'd languages in the agentic coding era. I think Rust is a locally optimal target for…

> There's less and less reason to use GC'd languages in the agentic coding era. Faster iteration, maybe? Rust's safety guarantee isn't exactly free (while still being very excellent) and does affect iteration time. I have a private project (>300K LoC) that has been translated from Python to TypeScript and the reason we couldn't use Rust was definitely the iteration time.

I like using Odin with LLMs for this. it's a simple statically typed language with no GC and very fast compile

Re: Rewriting Bun in Rust

#83

Post by bsder »

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…

Naive was 4-9% on the initial pass.

Also note that the larger percentages were against already smaller binaries. That smells like there was a single large constant number that got saved somewhere rather than general improvements.

> After that initial shrinkage, the team explored more opportunities for binary size reduction using linker optimizations like Identical Code Folding, removing unused data from ICU, and lazily decompressing small parts of libicu with a zstd dictionary on-demand.

I'd be VERY interested in seeing what the individual effects of those parts were.

Re: Rewriting Bun in Rust

#84

Post by johnfn »

giancarlostoro wrote: post #38

So I kept hearing that the author did this purely because Anthropic wanted a PR story, but reading this entire very well written post, with meticulous detail, what say you now? I never thought it made any sense for him to do this just because Anthropic asked him to. Sometimes you find yourself fighting the stack you're currently using, and another stack (or programming language) looks like it would alleviate a lot. L…

So much of the discourse around this on HN is nonsensical, and I fully agree with you. It's patently absurd that Anthropic would demand him to rewrite Bun into Rust; it's equally absurd that they would demand any sort of stunt at all when Anthropic already pulled off the biggest stunt with Bun: running Claude Code on it. And why on earth would you cannibalize the runtime of your golden goose?

Re: Rewriting Bun in Rust

#85

Post by frollogaston »

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 pay attention when someone makes a hard decision based on a hard-learned lesson. It's like, most who choose to use an ORM just heard of it or want to avoid learning SQL, everyone who removes an ORM learned firsthand horrors.

Re: Rewriting Bun in Rust

#86

Post by fps-hero »

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 realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever.

Re: Rewriting Bun in Rust

#88

Post by esjeon »

steveklabnik wrote: post #59
pavon wrote: post #54

Earlier quoted context omitted.

I think you are saying the same thing as benced - just because Zig source code is verbose is no reason to assume the binary should be larger.

I read my parent ask asking a question: is there a correlation, or not? I am saying that I do not believe there is a correlation between source code length and binary length. If that's what benced meant by their question, then yes, I agree :)

I’m quite sure there is a certain amount of correlation unfortunately, mainly because there are micro patterns (e.g. IO, allocator) that can’t be modularized into functions. Lots of manual copy-pasta.

Re: Rewriting Bun in Rust

#89

Post by steveklabnik »

14113 wrote: post #79
steveklabnik wrote: post #51

Earlier quoted context omitted.

I don't think you can draw the conclusion that source length and binary size are correlated. For example, in Rust: #[derive(Copy, Clone)] enum Expr { Int(i32), Add(i32, i32), Neg(i32), } fn eval(expr: Expr) -> i32 { match expr { Expr::Int(x) => x, Expr::Add(a, b) => a + b, Expr::Neg(x) => -x, } } Rust's enums can carry data. You can write the same thing in C, but because it does not have the enum feature, you have to…

It required a little bit of messing with optimisation settings and library generation in Rust, but they emit very very similar x86-64 assembly: https://godbolt.org/z/89W4srz4d

Nice, thank you for picking up after my laziness. Surely only a few bytes different in the binary, and much, much smaller of a delta than the source.

Re: Rewriting Bun in Rust

#90

Post by teach »

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…

You're entitled to call things as you wish, of course, but your definition of "vibe-coding" differs quite a bit from mine.
Post reply on HN