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

261–270 of 560 posts

Re: Rewriting Bun in Rust

#261

Post by lostglass »

m00dy wrote: post #223
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++.

yeap, unfortunately, only few can see this.

It's not though. It's fast enough for many applications but if you need to write a hypervisor then suddenly bounds checks and atomic pointers become significant. Not to mention that rust dramatically reduces your ability to control where memory is allocated.

I write in rust and c++, rust isn't as fast. Rust is easier to work with and, compared to the Java crap it's replacing at my work, it's a lot better but it's certainly not zero cost abstractions the way c++ can be, nor is it great for data oriented design because you're hoping the compiler will do the right thing, consistently.

Re: Rewriting Bun in Rust

#262

Post by flohofwoe »

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…

> and you decide to drop to down to C++

Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).

Re: Rewriting Bun in Rust

#263

Post by crote »

teach wrote: post #90
silver_silver wrote: post #81

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

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

500k lines in 11 days? With 8-hour working days that's 100 lines per minute. There's no way you're comprehensively reviewing code that quickly.

The code was generated by a LLM, and the output wasn't even read by its user. That's definitely vibe coding.

Re: Rewriting Bun in Rust

#264

Post by testdelacc1 »

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

Could you help me understand with an example or two? My understanding is that well written Rust and C++ are often identical in performance thanks to relying on the same compiler backend (both clang and rustc use LLVM).

Re: Rewriting Bun in Rust

#265

Post by flohofwoe »

m00dy wrote: post #223
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++.

yeap, unfortunately, only few can see this.

It depends a lot on the coding style. The sort of Rust code that's heavy on Rc, Arc, Box, RefCell etc... (e.g. the typical band-aids to work around borrow checker restrictions) will be slower than typical C++ code (it's also possible to kill performance in C++ of course, just use std::shared_ptr for everything). E.g. I'd wager that performant Rust code is trickier to write than performant C++ code because you'll have to design your entire Rust codebase around borrow checker restrictions, while C++ lets you 'cheat' without having to fall back to helper types that incur runtime overhead.

Re: Rewriting Bun in Rust

#266

Post by hdjrudni »

capiki wrote: post #257
jordand wrote: post #254

The thing you have to remember with that $165k spend on tokens is that token prices are going to keep rising, and models may not get much better. I wouldn't be surprised if doing this same migration in 6 months time would end up costing $250k+

do you think price per task completed will rise as well?

Isn't that equivalent? The task here was port Bun from Zig to Rust. He's saying that task will cost more.

Re: Rewriting Bun in Rust

#267

Post by yukIttEft »

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

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

Re: Rewriting Bun in Rust

#268

Post by cognitiveinline »

rvz wrote: post #193
minimaxir wrote: post #184

Earlier quoted context omitted.

As steveklabnik noted above, Hacker News does not have a meme-y culture. Just because you made a joke doesn't mean it's inherently immune to criticism, especially when using the lowest-effort, most-overdone meme around agentic development adds nothing to the discussion. Get new material.

> As steveklabnik noted above, Hacker News does not have a meme-y culture. For this one, yes it does. Go search this one up yourself. [0] Literally everyone in the comments in [0] and even the author of this post acknowledges the joke except for you two. It. Is. A. Joke. Calm down. > Just because you made a joke doesn't mean it's inherently immune to criticism No one is arguing that. It's OK that you won't admit that…

Everyone is calm. Many are just tired of you not taking a hint.

Re: Rewriting Bun in Rust

#269

Post by bigstrat2003 »

minimaxir wrote: post #235
galleywest200 wrote: post #136

Earlier quoted context omitted.

If you already employed the engineers the extra cost would have been $0.

https://en.wikipedia.org/wiki/Opportunity_cost

Opportunity cost is not a real cost. No money leaves your bank account. It is a decision making tool, and treating it as an actual financial cost is a misuse of the idea.

Re: Rewriting Bun in Rust

#270

Post by nsoonhui »

ignoramous wrote: post #145
dabinat wrote: post #101

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

> I suspect Claude might be faster and therefore cheaper, but maybe not by a lot. While Jarred used Mythos-class model, some open weights, if they were as capable (certainly, GLM 5.2 looks the part), would have been way, way cheaper than professionals. Approx costs: DeepSeek v4 Pro & Mimo v2.5 Pro $3,426 ($2,567 / $600 / $259) Tencent HY3 $3,892 ($1,180 / $552 / $2,160) GLM 5.2 $30,016 ($8,260 / $3,036 / $18,720) Qwe…

But not all models are equally capable, so I don't know your basis of comparison is even valid, let alone the numbers.
Post reply on HN