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

121–130 of 560 posts

Re: Rewriting Bun in Rust

#121

Post by piskov »

jeremyloy_wt wrote: post #120
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…

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

Re: Rewriting Bun in Rust

#122

Post by reinitctxoffset »

YuechenLi wrote: post #29

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows. People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of m…

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 ergonomic (take it up with Wadler memory chads, no one likes affine types).

I like lean4, which is dramatically safer, more succinct, and more ergonomic than Rust.

But I can see why some would say it's a bit too succinct.

Re: Rewriting Bun in Rust

#123

Post by baby »

pyrolistical wrote: post #15
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%.

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

Re: Rewriting Bun in Rust

#124

Post by JavierFlores09 »

himata4113 wrote: post #75

They didn't mention the cost of this. Assuming mythos was somewhat involved I'd extrapolate this as: 128 x20 max accounts needed which comes at $25.6k or over 75k in api costs. For 75k you can hire a team of engineers that would produce a better result with sematic conversion and other tricks used in porting from language A to language B at the cost of maybe taking 1 month instead of 10 days. I will be a lot more exc…

I don't think the realistic alternative here was “hire a team for a month and get a better semantic conversion”

For a rewrite of this size, the expensive part is deep understanding of the underlying system in order to preserve behavior while keeping performance, and above all that not freezing product work while doing it. Adding more engineers would just end up in managerial burden and review bottlenecks, to say the least.

So even assuming the API cost estimate is high, I don't buy the “just hire engineers for a month” take. A team unfamiliar with the codebase would probably spend a large chunk of that month just building context and deciding how not to break everything. A team familiar with the codebase is even more valuable doing product work, bug fixes, and review of the existing codebase.

So, in short, I do agree with the simple fact that this is still too expensive for most projects, but not with the idea that “a small team would trivially do better in a month”.

Re: Rewriting Bun in Rust

#125

Post by sashank_1509 »

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 hiring a SWE for 200k. I will say, at the very top for a software heavy company like Google or Anthropic, they will still hire excellent engineers to create new software that AI is not very good at.

But for companies where software is simply a cost center. Like Walmart, or Target, companies that were already outsourcing software development, or using cheap H1bs, now they have the alternative of AI which is much better than even hiring an average software engineer for 200k. This is a sea change in the job market, it’s going to have a pretty big effect as it is right now. US has around 1.6 Million software developers, this number is going to get cut drastically, the very top, say an L6 quality in FAANG will be fine, the average in a no name Bank, or the guy building the website for McDonalds is out, he needs to learn something else or he’ll end up without a job soon.

I would not have predicted this a year ago, now it seems clear that this will happen. Just shows how much of a sea change we have witnessed just like that.

Re: Rewriting Bun in Rust

#126

Post by pier25 »

incognito124 wrote: post #87

> In Bun v1.3.14, every build leaks about 3 MB, forever I'm sorry but that is insane, how was this never fixed before the rewrite?

I've been impacted by a couple of bugs in Bun.SQL and lo and behold these were only fixed for 1.4. Presumably Claude could have fixed those in the Zig version but the Bun team decided to not do that.

Furthermore, there's no mention of an LTS plan for the Zig version. It seems that if a CVE is discovered in the future, Bun users will no have no option than to update to the Rust port.

This is not how you run a project that others depend on and enough for me to not touch Bun ever again.

Re: Rewriting Bun in Rust

#127

Post by slopinthebag »

jeremyloy_wt wrote: post #120
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…

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 cost of them not working on other things).

Re: Rewriting Bun in Rust

#128

Post by h14h »

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

While it's easy to look at it that way on the surface, from reading the blog post, it sounds like a big part of it may just be the nature of Bun as a project.

Re: Rewriting Bun in Rust

#129

Post by Barrin92 »

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 that size seems like not a great way to go about this

Re: Rewriting Bun in Rust

#130

Post by malisper »

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.

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 unions do not.

I've been working on a new rewrite that's focused on beating Postgres on performance. As of this morning I got to 100% of the tests passing and have meaningful performance gains over Postgres.

Post reply on HN