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

211–220 of 560 posts

Re: Rewriting Bun in Rust

#211

Post by simonw »

duhhhhh1212 wrote: post #202
simonw wrote: post #180

Earlier quoted context omitted.

Have you seen the "rewrite by outsourcing to India" thing work?

What a weird thing to say. The phrase “outsourcing to India” being used as shorthand for “you don’t need top engineers.” The nationality stereotypes are mean and degrading.

That's fair, I shouldn't have commented that. I don't like the national stereotypes at all - I see "outsource to India" as being more about less expensive engineers than not needing "top engineers".

That said, I don't think "rewrite from one language to another" with inexpensive engineers is a pattern that works. Happy to be proven wrong.

Re: Rewriting Bun in Rust

#212

Post by tclancy »

piskov wrote: post #121
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…

Unless you hire smart people from EU and what have you (especially ex-USSR) Which takes us to a point of future US dev salaries if this thing with agents gets better more and more

Sure, but can we not work out how to make humans more efficient for less money? There are obvious optimizations there that none of us would like to be part of.

Re: Rewriting Bun in Rust

#213

Post by cube00 »

thevinter wrote: post #3

One thing that I found interesting is that most of the discourse surrounding the topic happened with the assumption that the rewrite was happening with an Opus-like model, and not with Fable. Those assumptions, at least partially, were used as arguments against the fact that the rewrite was feasible and/or a good idea. Clearly the model itself doesn't completely change the narrative, but at least as a note to myself,…

> the assumption that the rewrite was happening with an Opus-like model, and not with Fable

I thought the same thing. Looking back, I was probably mislead in May when Jarred was explaining the pattern to "Rewrite every .zig file to .rs" as if it was something I could have done in May following his pattern. What he wasn't telling us was he was using pre-release Fable. [1]

A possible signal for next time is when we see an Anthropic owned company disabling the Claude Co-Authored-By trailer. [2] In an IPO year they have to take every chance to promote Claude unless it was something (Fable) that we weren't supposed to know about back in May.

[1]: https://xcancel.com/jarredsumner/status/2060050586024743376#...

[2]: https://github.com/oven-sh/bun/commit/23427dbc12fdcff30c23a9...

Re: Rewriting Bun in Rust

#214

Post by [deleted] »

throwaway27448 wrote: post #18
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%.

True, but rewrites often allow for this sort of benefit in themselves. It's possible rewriting it in zig would have yielded some of the same improvements.

[deleted]

Re: Rewriting Bun in Rust

#215

Post by cognitiveinline »

einsteinx2 wrote: post #154
simonw wrote: post #93

Earlier quoted context omitted.

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

Fable is kind of fantastic on the difficult tasks. if it's something eithe rmodel can do then you can't see the difference. Fable also makes much less mistakes. It's a more relentless, proactive problem solver.

Re: Rewriting Bun in Rust

#216

Post by malisper »

xeromal wrote: post #207
malisper wrote: post #130

Earlier quoted context omitted.

I can confirm a naive rewrite won't make things faster. I've been working on rewriting Postgres in Rust. I rewrote things function by function similar to how Jarred did. Even though the new Rust code mapped closely with the previous C code, it was 8x slower. This was due to myriad of reasons. For example naively converting a C union into a Rust enum can be slower because Rust stores a tag with the enum, while C union…

Would love to follow your journey!

If you want to follow along, I've been writing about it on my blog (https://malisper.me/) an you can follow the github repo here: https://github.com/malisper/pgrust

Re: Rewriting Bun in Rust

#217

Post by [deleted] »

pier25 wrote: post #140

Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time. What has pushed me back to Node is seeing how amateurish the transition has been handled. - No LTS support for the Zig version regarding CVEs etc. - Huge bugs like the 3MB memory leak mentioned in the blog post abandoned in the Zig version to basically force people into the Rust vers…

[deleted]

Re: Rewriting Bun in Rust

#218

Post by xeromal »

malisper wrote: post #216
xeromal wrote: post #207

Earlier quoted context omitted.

Would love to follow your journey!

If you want to follow along, I've been writing about it on my blog ( https://malisper.me/ ) an you can follow the github repo here: https://github.com/malisper/pgrust

Bookmarked. I love ambitious projects like this. I'll check in!

Re: Rewriting Bun in Rust

#219

Post by gwenzek »

Philpax wrote: post #110
simonw wrote: post #93

Earlier quoted context omitted.

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.

Oh, I have no doubt that they could have extracted those gains from Zig! My point is more that, from a relatively naive line-to-line port, they were able to claim these benefits without much effort. It's not great for Zig if you have to put in more work to end up at the same place efficiency-wise, especially for a language marketed at people who like to get the most out of their metal.

That's not what the article says though. The size reduction was from extra linker flag for deduping code, and the speed gains from LTO.

They could have done the same in Zig, even though it probably shows cargo is better at this than build.zig.

Re: Rewriting Bun in Rust

#220

Post by vlovich123 »

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…

For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO.

[1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/

Post reply on HN