[dead]
Rewriting Bun in Rust
111–120 of 560 posts
Re: Rewriting Bun in Rust
#112Earlier 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.
> 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?
Claude code is buggy and they don't appear to be maintaining it just fine.
Re: Rewriting Bun in Rust
#113Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…
> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026.
The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction, whereas Rust asks that you think in terms of ownership. This is not preferable ergonomics to many.
I realize what I'm saying above, while true, doesn't give a clear example. Many gamedevs would rather iterate with a language that is lower friction, not only because game code is finnicky (like frontend UI code) but because the build process can be unique. Many gamedevs prefer to iterate with hot-reloading, and asking them to use a slower compiler is asking them to accept greater latency in that cycle.
I do not claim that these reasons apply to everyone.
Re: Rewriting Bun in Rust
#114>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?
Why? Python is terse but has large binaries because of the runtime overhead. C++ is fairly verbose but can make useful binaries in double digit kib.
Re: Rewriting Bun in Rust
#115I still think that generating a Zig-Rust transpiler would be a better approach, given all the LLM quirks, including the ability to just /goal the model with binary-identical LLVM bytecode. However, an open-sourced tool like that would've greatly harmed the Zig ecosystem and community.
Go famously used machine translation to remove dependency from C. It's a nice way to retain structural familiarity with the target language. I imagine they could've saved a large portion of that $165,000 using this route. Hard to say for certain, though. You wouldn't want to scope that transpiler at "being able to transpile all programs generally," and so scoping the project does become a serious task.
Re: Rewriting Bun in Rust
#116Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…
> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any add…
The comment you're replying to wasn't arguing rust > GCed languages (e.g. C# or whatever game dev language you are thinking of). It was arguing rust > non-GC non-safe languages (e.g. zig).
Re: Rewriting Bun in Rust
#117Earlier quoted context omitted.
> 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?
Claude code is buggy and they don't appear to be maintaining it just fine.
I use it all day every day and haven’t noticed any bugs.
And the fact is that they are maintaining it and it is one of the most successful software products of all time and is earning them mountains of cash. By any metric it is a successful product. So obviously whatever they are doing is working.
Re: Rewriting Bun in Rust
#118Earlier quoted context omitted.
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.
What would be the consequence to them if they did screw it up? Screwing up the maintainability of a project, especially a big one, doesn't necessarily have immediate consequences. The fallout could be delayed by a year or more. Also, they have effectively limitless tokens to burn on keeping everything looking OK, and a vested interest in doing so.
I'm not trying to spin up some kind of conspiracy theory here, but I'm not sure to what extent Anthropic does have any vested interest in this project (in fiscal terms at least) because the reputational fallout could be significantly delayed and might just not be big enough to matter.
Re: Rewriting Bun in Rust
#119>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…
Zig is indeed verbose in some aspects, but not overall. For example, its `try error-union` syntax eliminates a lot of boilerplate code.
The main reason why Zig is verbose in some aspects is the main goal of Zig is program performance. It is a worthy tradeoff.
Re: Rewriting Bun in Rust
#120> This Rust rewrite would've taken a team of engineers with full-context on the codebase a year of work. With 1 engineer using Fable & closely monitoring Claude Code, we went from start to 100% of the test suite passing on all platforms in 11 days. This is impressive from a technological standpoint, but it does gloss over the fact that it would have cost $165k in tokens were Bun not part of Anthropic. The comparison…
They napkin math is fairly easy to do. One human works around 250 days per year, and if we assume Bay Area salaries we could assume ~300k/y conservatively for a fully loaded cost.
$1200 per day.
Your estimation is 50*11 days so $660,000. That’s 4x what Claude cost.
That’s assuming that you actually get those 50 people to work without blockers, stepping on each other, or other coordination issues. The coordination complexity alone is astounding.
I don’t like it necessarily, but Claude wins here, easily. It’s not close.