Rewriting Bun in Rust • Hacker News Board

Re: Rewriting Bun in Rust

#271

Post by iknowstuff » Thu, Jul 09, 2026, 6:51 AM UTC

yukIttEft wrote: post #267

josephg wrote: post #204

Earlier quoted context omitted.

> I can understand when you need the absolute best performance and you decide to drop to down to C++ Rust is just as fast as C++.

Is it though. There are so many situations where something is guaranteed to be safe but there is no way to express that in the Rust typesystem, so the only thing you can do is to wrap everything in Arcs and Mutexes, which introduces allocations, pointerchasing and locks

Hard to imagine a scenario where you don’t need a mutex for correctness and yet somehow Rust forces you to do it?

Unless maybe you mean tokio’s work stealing executor, but you can just not use it.

Re: Rewriting Bun in Rust

#272

Post by cognitiveinline » Thu, Jul 09, 2026, 6:52 AM UTC

pier25 wrote: post #55

Georgelemental wrote: post #37

Earlier quoted context omitted.

Pre-release code had bugs that were fixed before the release? Why is that a problem? That's the point of having a testing and release process

what about new bugs introduced after the rewrite?

Got a reference to something specific? Per the blog post the overall quality, speed and size all improved. And multiple users have corroborated.

Like have you run into a specific bug or seen a regression - that's the cause of your reaction?

Re: Rewriting Bun in Rust

#273

Post by stymaar » Thu, Jul 09, 2026, 6:57 AM UTC

leecommamichael wrote: post #113

didibus wrote: post #80

Article 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 rust compiler is very slow.

It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it.

> The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many.

In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.

Re: Rewriting Bun in Rust

#274

Post by ozgrakkurt » Thu, Jul 09, 2026, 7:03 AM UTC

hdjrudni wrote: post #259

ozgrakkurt wrote: post #239

Earlier quoted context omitted.

It is highly debatable if a 200k cost engineer that is suitable for the job wouldn’t bring in more value. Also it is debatable they got any value at all from this. Anyone who wrote unsafe rust and also wrote zig would know that unsafe rust is much much more unsafe in comparison

It's only 4% unsafe and most of it is single-line pointers that came from C++ > At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I don't know much about Rust but I imagine this is safer than 100% 'unsafe' code in Zig or…

4% of 100k is 4k. 4k lines of unsafe rust is more likely to be unmanageable compared to 4k lines of zig or c dependency on a 100k line rust codebase.

Not sure if they have 100k or a million lines of code

Re: Rewriting Bun in Rust

#275

Post by worldsavior » Thu, Jul 09, 2026, 7:03 AM UTC

sashank_1509 wrote: post #125

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…

Getting tired of these comments trying to hype AI. All of us use AI, and if we don't, we have a reason. Chill.

Re: Rewriting Bun in Rust

#276

Post by [deleted] » Thu, Jul 09, 2026, 7:04 AM UTC

losvedir wrote: post #156

In what ways does Anthropic use Bun? I know it's used as the "runtime" for Claude Code, but rather than porting a million lines of Zig to Rust, why not just port Claude Code to rust and not need to bundle a JS runtime at all? Does Anthropic use Bun otherwise? Maybe for JS execution tool calls in Claude responses?

[deleted]

Re: Rewriting Bun in Rust

#277

Post by hdjrudni » Thu, Jul 09, 2026, 7:04 AM UTC

jatins wrote: post #238

Extremely thorough and well written. I was hoping it’d end in a “so how much did this cost?” so that others team looking at similar migrations have an estimate on what they can expect

> I was hoping it’d end in a “so how much did this cost?” so that others team looking at similar migrations have an estimate on what they can expect

It was in the middle. $165k.

Re: Rewriting Bun in Rust

#278

Post by voidUpdate » Thu, Jul 09, 2026, 7:08 AM UTC

I wonder how much the authors now understand their project? Like, if they were given a bug, would they be able to intuit a possible location in their files that might be causing it? Or are they now essentially locked in to using LLMs to write/rewrite their code?

Re: Rewriting Bun in Rust

#279

Post by rootlocus » Thu, Jul 09, 2026, 7:10 AM UTC

didibus wrote: post #80

Article 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…

Im constantly surprised by the disk size required by rust builds. It takes over 50G to compile zed IIRC.

Re: Rewriting Bun in Rust

#280

Post by flohofwoe » Thu, Jul 09, 2026, 7:14 AM UTC

kibwen wrote: post #164

henry_bone wrote: post #148

Earlier quoted context omitted.

I'll bite. The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it. Rust is pushed by many as the replacement to C, because of the memory safety guarantees. I'm sympathetic. I worked with Haskell for a time, so I get it. But Rust seems quite complex. There are so many language features that there's memes about it. There's also…

> There are so many language features that there's memes about it. Like many memes, these are misleading. Rust is a solidly medium-sized language; smaller than Python, certainly, though with a perilously steeper learning curve than Python.

Rust-the-language may be medium-sized. Rust-the-stdlib though?

The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean?

https://doc.rust-lang.org/std/cell/struct.RefCell.html

E.g. what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust, just because Rust needs the additional information to do its memory safety magic correctly.

The entirety of Rust and its stdlib has a huge 'semantic surface' compared to most other languages (even C++), and I think this difference in the semantic surface size to other languages is exactly the one thing that either attracts or repels people to/from Rust ;)