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

181–190 of 560 posts

Re: Rewriting Bun in Rust

#181

Post by sitzkrieg »

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…

rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.

Re: Rewriting Bun in Rust

#182

Post by Gigachad »

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…

I'm not so pessimistic. There is an infinite amount of work that could be done. No one would have entertained the idea of rewriting a project in Rust before this. It hasn't replaced anyone's actual job and they still had to hire a high paid employee to pull it off.

I suspect rather than hire less people we will just produce more code changes.

Re: Rewriting Bun in Rust

#183

Post by nvader »

malisper wrote: post #130
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.

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…

I hope that you're going to call it PostGrust.

Re: Rewriting Bun in Rust

#184

Post by minimaxir »

rvz wrote: post #73
QuaternionsBhop wrote: post #41

Earlier quoted context omitted.

Jokes require mutual context. You failed to create a joke because you did not ensure the prerequisites were met.

> Jokes require mutual context. The article itself is the context. Even the chatbots: ChatGPT, Claude and Gemini 'understand' the joke in the comment. Go ahead and ask them. > You failed to create a joke because you did not ensure the prerequisites were met. The prerequisites was for you to read the article first. The joke: "Now Claude, rewrite Claude Code from TypeScript to Rust. Make absolutely zero mistakes." You:…

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.

Re: Rewriting Bun in Rust

#185

Post by internet2000 »

bhaak wrote: post #143
Jenk wrote: post #109

Earlier quoted context omitted.

$165k won't get you far on salaried engineers. There's every chance that 1 engineer, assuming Anthropic employs them, is on $500k or more. Assuming average of $336k in that pool of 50 engineers, then for 11 days for 50 engineers you've spent $710k[0]. Salary info: https://www.levels.fyi/companies/anthropic/salaries/software... [0]The maths I used (posting because I'm tired and prone to mistakes): $336,000 / 260 (work…

You don't need top engineers to port a program from one language to the other. Outsource it to India. Of course, then you can also ask, could it have been done with a cheaper model. Probably yes. But then you wouldn't get free marketing.

Outsourcing to India would actually be the disaster the naysayers were saying this would be.

Re: Rewriting Bun in Rust

#186

Post by zamalek »

atrevbot wrote: post #157
zamalek wrote: post #138

Earlier quoted context omitted.

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?

One option would be to have an input replay alongside captured outputs (audio visual), at some fixed framerate. Capturing intermediates (scene graph etc.) would probably also be valuable, as that could help nail down why something is failing.

Or you could do it [as I recall the project being called] the scientist way. You still have the old code, so you could replay inputs against each and compare. Probably more realistic because uncompressed video would be a ridiculously huge dataset. This would be more resilient in the face of testing hardware and driver drift.

Historically game engines are the worst offenders when it comes to unit testing. I'm not sure if that's still the case - but that's why I erred on the side of integration tests.

Re: Rewriting Bun in Rust

#187

Post by steveklabnik »

sitzkrieg wrote: post #181
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…

rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.

> way too big

https://github.com/tormol/tiny-rust-executable

This produces a 137 byte binary. Obviously AMD64 isn't used in embedded, but I've seen ARM ones that are in the ~256 range.

It's all in how you use it. Of course, if you don't care about binary sizes, they can get large, but that's very different than actually paying attention to what you're doing.

Re: Rewriting Bun in Rust

#188

Post by steveklabnik »

aw1621107 wrote: post #158
steveklabnik wrote: post #89

Earlier quoted context omitted.

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.

Ah yeah, honestly both should probably be passed by pointer anyway. But that makes me wonder about the actual differences here and why... maybe something fun to dig into.

Re: Rewriting Bun in Rust

#189

Post by iknowstuff »

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…

1.4 has no breaking changes from 1.3 so why would there be an LTS and any guarantees for people staying on 1.3? All known regressions have been fixed like any other release as far as I can tell

Re: Rewriting Bun in Rust

#190

Post by pier25 »

alexjurkiewicz wrote: post #166
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…

Paying customers get LTS. Are any paying customers asking for a Zig branch LTS? Or are you expecting open source maintainers to do free work for no particular reason?

Java, Node, and .NET have LTS versions all of which are free to use.

> Or are you expecting open source maintainers to do free work for no particular reason?

Free work? Last I heard Anthropic had acquired Bun.

Post reply on HN