Rewriting Bun in Rust • Hacker News Board

Re: Rewriting Bun in Rust

#221

Post by atonse » Thu, Jul 09, 2026, 5:09 AM UTC

pier25 wrote: post #196

atonse wrote: post #170

Earlier quoted context omitted.

LTS is more relevant if there was any kind of compatibility that was broken. They still haven’t released 1.4 even though it seems to have gone extremely well by every metric in the wild, with tons of people using Claude code with no regressions in a month. Nothing to me suggests they’re being careless here. In fact, he had two adversarial reviewer Claude instances on every code change, every line. I don’t know a sing…

> LTS is more relevant if there was any kind of compatibility that was broken Do we know 100% for certain that this isn't the case? No. In fact it would be naive to think a rewrite of this magnitude wouldn't introduce new bugs and/or unexpected changes in behavior. > Nothing to me suggests they’re being careless here. Plenty of reasons suggest this including the lack of an LTS or any kind of thought put into such a m…

Again, the code’s been out for two months. And by many accounts, many people would clearly love to scream loudly about all the things that broke.

There were initial analyses done on the port. And things continue to get refactored. But is there any slam dunk article where someone actually found any regression in functionality or stability? We’re seeing the opposite. Dozens of bugs fixed. We don’t have to theorize. They’ve been running this experiment for 2 months, with all the code out in the open.

It just feels like after two months, people want to cling to the _idea_ that this was reckless, without evidence of any meaningful negative impact.

Re: Rewriting Bun in Rust

#222

Post by comex » Thu, Jul 09, 2026, 5:18 AM UTC

kibwen wrote: post #137

leecommamichael wrote: post #113

Earlier quoted context omitted.

> 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 best way to speed it up appears to be organizing a codebase in many crates. A "crate" in Rust is the unit of compilation. In C, a file is the unit of compilation. Rust just lets you have a compilation unit that's composed of more than one file (without having to resort to C-style textual inclusion). But if you want, you can certainly have one-file-per-crate, just like you would in C. And what's nice about havin…

The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?

In C, usually yes.

In C++, sometimes yes. It depends on how template-heavy the code is, but if you have some discipline you can keep most logic out of headers and thus easily splittable.

In Rust, almost always no, because of circular dependencies. You can try to work around it by adding `dyn Trait` everywhere, but that requires a lot of code changes and comes at big ergonomic costs (and a small runtime cost).

Which is why in practice, Rust compilation units are almost always larger than C++ or C compilation units. Rust can sometimes be competitive with C++ on compilation speed anyway, thanks to a smarter build system and not having to re-parse headers a billion times, but usually it's slower.

Re: Rewriting Bun in Rust

#223

Post by m00dy » Thu, Jul 09, 2026, 5:22 AM UTC

josephg wrote: post #204

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…

> 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++.

yeap, unfortunately, only few can see this.

Re: Rewriting Bun in Rust

#224

Post by [deleted] » Thu, Jul 09, 2026, 5:22 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…

[deleted]

Re: Rewriting Bun in Rust

#225

Post by m00dy » Thu, Jul 09, 2026, 5:22 AM UTC

Rust is the clear winner of LLM era. You can't say otherwise.

Re: Rewriting Bun in Rust

#226

Post by Zetaphor » Thu, Jul 09, 2026, 5:25 AM UTC

simonw wrote: post #178

27183 wrote: post #118

Earlier quoted context omitted.

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…

Claude Code is the main reason their revenue (ARR) grew from $9bn to ~$47bn in the first half of this year. That's a very big reason not to screw this up.

It's far less obvious how choosing Bun results in more revenue for Anthropic. Unlike Claude Code, Bun doesn't require you to pay for tokens to use it

Re: Rewriting Bun in Rust

#227

Post by diarrhea » Thu, Jul 09, 2026, 5:27 AM UTC

Gigachad wrote: post #182

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…

I'm not so pessimistic. There is an infinite amount of work that could be done. No one would have entertained the idea of rewriting a project in Rust before this. It hasn't replaced anyone's actual job and they still had to hire a high paid employee to pull it off. I suspect rather than hire less people we will just produce more code changes.

But do the markets care about a Postgres in Rust? Probably not, or at least not right away. It is a long way towards commercial success.

> I suspect rather than hire less people we will just produce more code changes.

Why? Towards what end? Code changes are output, not outcome. It also needs to be connected to someone willing to pay you hard cash. That is the hard part, a race to the bottom, and the reason I also believe there will be downwards pressure on salaries and even employment.

Re: Rewriting Bun in Rust

#228

Post by Tadpole9181 » Thu, Jul 09, 2026, 5:27 AM UTC

pier25 wrote: post #190

alexjurkiewicz wrote: post #166

Earlier quoted context omitted.

Paying customers get LTS. Are any paying customers asking for a Zig branch LTS? Or are you expecting open source maintainers to do free work for no particular reason?

Java, Node, and .NET have LTS versions all of which are free to use. > Or are you expecting open source maintainers to do free work for no particular reason? Free work? Last I heard Anthropic had acquired Bun.

Are you asking for an LTS Zig version as a member of Anthropic?

Re: Rewriting Bun in Rust

#229

Post by m00dy » Thu, Jul 09, 2026, 5:30 AM UTC

baby wrote: post #123

pyrolistical wrote: post #15

Earlier quoted context omitted.

Yeah but they turned it into something unreadable. Call it a skill issue if you wish. I just haven’t found another language that just makes sense. Zig doesn’t hide anything from you

I find Rust more readable than zig

you're not alone.

Re: Rewriting Bun in Rust

#230

Post by reinitctxoffset » Thu, Jul 09, 2026, 5:30 AM UTC

metaltyphoon wrote: post #206

reinitctxoffset wrote: post #122

Earlier quoted context omitted.

The twenty percent quoted is referring to the size of the compiled artifact (one assumes ELF or Mach-O). Whether or not a language is verbose or obscure is very much about your coordinate system. Not unlike safety. I think C is a reasonable zero for both things. Zig is more succinct and safer than C while still being comparably ergonomic. Rust is (mostly) safer and more succinct than Zig while being dramatically less…

> Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic This is just your opinion.

Well, it's my opinion. But it's also the opinion of the broader functional programming community from 1993 to the present day. This notably includes the quite serious Haskellers who designed Rust for the highly specific and demanding requirements of the Servo rendering engine in ~2010. Being as my two parents in web browser layout optimizations were both filed in 2009 I took considerable interest.

It wasn't until 2014 that Orchard formalized the coeffect discharge calculus via indexed monad that makes a binary ownership semantic irretrievably sunsetted as a degenerate case.

It's my opinion. I'm not concerned about how informed that opinion is.