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

151–160 of 560 posts

Re: Rewriting Bun in Rust

#151

Post by frizlab »

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…

My personal memory and concurrent-safe option is Swift. And I agree, choosing a non-memory safe language for a new project is close to irresponsible today…

Re: Rewriting Bun in Rust

#152

Post by benced »

BearOso wrote: post #74
benced wrote: post #57

Earlier quoted context omitted.

I would guess the cost to do this with humans would be _at least_ $1.5M in compensation alone (I'm thinking three 500k/year Bay Area engineers) so this is already an order of magnitude cheaper. Is it worth $165K? I'm less sure of that but it's honestly a moot point - this will get to 5 then 4 digits of cost pretty fast.

I think putting it in terms of API pricing is oversimplifying disingenuously. Anthropic still hasn't pulled the rug out from under us, so I'm sure it cost a great deal of money once everything comes together, likely surpassing 1.5M. Summarily, they got the result faster, which a group of engineers couldn't do, but at a greater expense.

GLM 5.2 (open-weights) is at or near Opus 4.7 level performance already. I think it's unlikely Anthropic will be able to durably charge us much more than the CapEx depreciation cost of GPUs + the OpEx of running them for non-frontier models (which Fable will be in 6 months to a year).

Re: Rewriting Bun in Rust

#153

Post by dgacmu »

pier25 wrote: post #144
dgacmu wrote: post #142

Earlier quoted context omitted.

I'm a little puzzled: Why should you care? The language in which Bun is written isn't part of its API, if you will. You care that you have something that does various javascripty things according to a particular spec of what it's supposed to do. If a bug is fixed in 1.4.x it's fixed, why should it matter, really, if that's in Zig or Rust?

Who in their right mind would immediately migrate their production apps into a complete re-write of a runtime? It would be naive to think there aren't new bugs or changes in behavior introduced in 1.4.

(Well, the answer is "Anthropic, with claude code", but I'm not in possession of material information related to whether they are or are not in their right minds.)

But yes, of course there will be new bugs. But that's why 1.4.x for x > 0 is interesting. If the branch is being used and people are not reporting _more_ bugs, and the bugs you care about it are being fixed (successfully) on it, and it passes your tests, etc., ... I dunno. This is an application domain where you can do some pretty solid testing of it, comparative fuzzing, etc., so it doesn't strike me as entirely mad to jump over after a few minor releases where you can see the bug trajectory.

Re: Rewriting Bun in Rust

#154

Post by einsteinx2 »

simonw wrote: post #93
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

I don't think it's care to categorize this as "a naive rewrite away from [Zig]" - Jarred has been immersed in this project for five years, got to benefit from everything he learned along the way and spent $165,000 of tokens on the most advanced coding LLM anyone has access to. I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.

> and spent $165,000 of tokens on the most advanced coding LLM anyone has access to.

After having used 2 full weeks of 20x Max plan tokens on Fable over the weekend (coding all day Saturday and Sunday on a non-trivial project, tasks across full stack, mix of adding features, reviewing code, and fixing bugs), I’m confident if he’d spent $165,000 in Opus tokens the port would have gone more or less just as well (and probably for less than $165,000). Especially so with the system they set up with all the custom workflows, adversarial reviews, extensive test coverage, etc.

But I get your point is probably more about Jarred’s experience level and the high cost than the specific model used other than it being SOTA. I’m just being pedantic and feeling a bit disappointed with Fable’s real world performance after all the hype.

> I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.

Totally agree and in fact I’m sure it could be done with significantly less cost even if they stuck with Fable instead of Opus which I’m sure could also do it.

Re: Rewriting Bun in Rust

#155

Post by [deleted] »

BearOso wrote: post #74
benced wrote: post #57

Earlier quoted context omitted.

I would guess the cost to do this with humans would be _at least_ $1.5M in compensation alone (I'm thinking three 500k/year Bay Area engineers) so this is already an order of magnitude cheaper. Is it worth $165K? I'm less sure of that but it's honestly a moot point - this will get to 5 then 4 digits of cost pretty fast.

I think putting it in terms of API pricing is oversimplifying disingenuously. Anthropic still hasn't pulled the rug out from under us, so I'm sure it cost a great deal of money once everything comes together, likely surpassing 1.5M. Summarily, they got the result faster, which a group of engineers couldn't do, but at a greater expense.

[deleted]

Re: Rewriting Bun in Rust

#156

Post by losvedir »

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?

Re: Rewriting Bun in Rust

#157

Post by atrevbot »

zamalek wrote: post #138
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…

Game engines are typically in two languages, one for the engine itself and one for scripting. That even goes for Unity: in Unity, C# is a significantly more powerful than average scripting language (for lack of a better term), but the engine itself is still C++. That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it does…

As someone who has almost no familiarity with game engines, it seems the success of this port was largely possible due to a comprehensive test suite written in a runtime agnostic way. What might be the equivalent test suite implementation required to successfully port a game engine to another language?

Re: Rewriting Bun in Rust

#158

Post by aw1621107 »

steveklabnik wrote: post #89
14113 wrote: post #79

Earlier quoted context omitted.

It required a little bit of messing with optimisation settings and library generation in Rust, but they emit very very similar x86-64 assembly: https://godbolt.org/z/89W4srz4d

Nice, thank you for picking up after my laziness. Surely only a few bytes different in the binary, and much, much smaller of a delta than the source.

You can further reduce the difference by passing Expr by pointer in the C version. At that point I think the only difference in the assembly is the order in which the cases are handed.

Re: Rewriting Bun in Rust

#159

Post by kvuj »

kgeist wrote: post #45
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

>they turned it into something unreadable Did you compare the code before/after? It's a mechanical line-by-line port, and most of the code is identical to the old version, just with Rust syntax. They have an example in the blog post.

But how can it be a mechanical rewrite if the tool used isn't deterministic?

Re: Rewriting Bun in Rust

#160

Post by atonse »

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…

Post reply on HN