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

281–290 of 560 posts

Re: Rewriting Bun in Rust

#281

Post by aldanor »

testdelacc1 wrote: post #264
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).

Even, possibly, the other way around in some cases. A seemingly identical program may (and it does occur) compile to a faster machine code in rust than in C++ due to extra markers (eg alignment) that rust compiler is able to provide to llvm.

Re: Rewriting Bun in Rust

#283

Post by tick_tock_tick »

slopinthebag wrote: post #127
jeremyloy_wt wrote: post #120

Earlier quoted context omitted.

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

Why assume the upper level salary here? Using senior level developers making astronomical salaries for what is a mechanical line-by-line port would be a poor financial decision. What does the math look like with 25 devs making ~100k and doing it in 22 days? I’m sure you could find a reasonable combination which costs less. And if you’re already paying the devs the salary, it’s basically free (minus the opportunity co…

> Why assume the upper level salary here?

Even a junior is going to cost you $200k by the time you're done paying payroll taxes, healthcare, etc.

Re: Rewriting Bun in Rust

#284

Post by OtomotO »

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

What? Rust generally doesn't have worse performance to C++, so this argument makes no sense at all to me.

> and I also relate with just personal preference, but beyond those it seems a no brainer to me.

That's another argument altogether.

It's totally fine to have preferences and decide to go with them of course.

Re: Rewriting Bun in Rust

#285

Post by KronisLV »

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…

I did some more sizeable work with GLM 5.2 on Max reasoning (planning and implementing 8 features end to end) and it performed pretty well, but worse than Opus 4.8, with largely the same adversarial agent review loop.

Opus 4.8 still found some real issues afterwards and spent about an hour fixing things, before the code was good enough to ship. Overall promising, wrote about it here: https://blog.kronis.dev/blog/z-ai-s-glm-5-2-is-a-great-model...

The GLM Coding Plan seems to have lower token limits than the corresponding Anthropic Max subscriptions, but if you had to pay API rates for some LLM to do work somewhat reliably, it's a no brainer (unless you're swimming in money that you can give away and value your time more).

Re: Rewriting Bun in Rust

#286

Post by crote »

Buttons840 wrote: post #107
ameliaquining wrote: post #94

Earlier quoted context omitted.

So does that mean the rewrite made you less skeptical?

Yeah, I guess. Now it appears to be a project run by Anthropic and I'm sure the real focus is on making money--which is still slightly different than having the focus be on making the best tool.

"Make more money" in this case could also be "do high-profile rewrite for marketing reasons, silently abandon a year later".

Re: Rewriting Bun in Rust

#287

Post by KronisLV »

atonse wrote: post #160
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?

I’ve wondered the same. Especially because codex is written in rust. Why not just port Claude code over. But my guess is that maybe it doesn’t have as robust a test suite? This might embolden them to do it…

> But my guess is that maybe it doesn’t have as robust a test suite?

Not sure about what's going on over there, but over the last year Claude Code has gotten way better, I sure hope that they're working on a good enough test suite to avoid a crapload of regressions (and pave way for more refactoring, should they need it).

Re: Rewriting Bun in Rust

#288

Post by ksec »

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…

Not only that. I think most of us, including the author wouldn't have thought this was actually feasible.

Not only is the time and dollar spent lower than a lot of people expected. We could now foresee a lot of these human interaction, mistakes, time and cost could be further reduced by a factor of 2, 5 or even 10+ in the not far future.

Also worth taking into account what is stated in the blog post is also acting as PR piece for Claude and LLM in general.

Re: Rewriting Bun in Rust

#289

Post by OtomotO »

stymaar wrote: post #273
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 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 w…

I am using Rust since 2016 productively... before I dabbled with it.

Rust is not compiling any slower than a comparable C++ codebase for me.

It is compiling much slower than a managed language like Kotlin, C# etc. though. Which is an unfair comparison anyway.

The problem with e.g. gamedev is the iteration cycles. It's very creative work and not so much your average engineering job (apart form game engine dev).

But again, that's an unfair comparison, because even in Unity and many if not most other game engines, there is a scripting language that is used for most of the game logic, that doesn't need hyper performance...

Still, when compared to such languages, Rust indeed does compile slowly AND one has to say: Rust is selling itself not only as a safe, blazingly fast systems programming language these days, but it also is used for its type system etc. and then, when you come from a managed language, compile times really suck.

(Although debug builds are better, they are not an option for game dev for example, because the binary is just too slow then... 200fps vs. 20 :X)

Re: Rewriting Bun in Rust

#290

Post by crote »

Barrin92 wrote: post #129

the thing I don't understand about this, given that the goal was a line-by-line transpilation, and the author had already transpiled it once from Go to Zig, why not write an actual transpiler? A problem is as complex as the smallest program required to solve it, and having an LLM, which doesn't produce deterministic output churn through almost 200 grand when you only need to write a deterministic program maybe 5% of…

Because the author isn't employed by a transpiler company.

The entire point is to get people to spend money on LLMs. Writing a transpiler - even a LLM-coded one - pretty much defeats the purpose.

Post reply on HN