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

191–200 of 560 posts

Re: Rewriting Bun in Rust

#191

Post by these »

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…

> That’s assuming that you actually get those 50 people to work without blockers, stepping on each other, or other coordination issues. The coordination complexity alone is astounding.

This is a question of exceptional management, which needs to be present both in the Claude and human cases, and is scarce. Not everyone given the Claude tokens would be able to deliver the same result.

Re: Rewriting Bun in Rust

#192

Post by jamesfinlayson »

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?

Gosh, I don't think any game engines have particularly good test suites at all. GoldSource and Source are the only ones that I have any real experience with and neither seems to have anything (Source may have a handful of things but nothing approaching baseline let alone comprehensive).

I have no idea how game devs handle big refactors other than lots of manual testing.

Re: Rewriting Bun in Rust

#193

Post by rvz »

minimaxir wrote: post #184
rvz wrote: post #73

Earlier quoted context omitted.

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

> As steveklabnik noted above, Hacker News does not have a meme-y culture.

For this one, yes it does. Go search this one up yourself. [0]

Literally everyone in the comments in [0] and even the author of this post acknowledges the joke except for you two.

It. Is. A. Joke. Calm down.

> Just because you made a joke doesn't mean it's inherently immune to criticism

No one is arguing that. It's OK that you won't admit that you didn't get it either.

> especially when using the lowest-effort, most-overdone meme around agentic development adds nothing to the discussion. Get new material.

You're being over-dramatic. Why is that you can't take a simple joke? Surely you've never joked on this site before.

[0] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: Rewriting Bun in Rust

#194

Post by eightyfive »

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…

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

All that really proves is that you’d be an astoundingly poor choice to hire. If you’re spending $200k on someone that doesn’t know at least two out of three (context, Rust, or Zig), you’re just burning money.

That’s not to say that experienced engineers familiar with the stack would or wouldn’t be able to do it in a year, but they’d certainly have a better shot at it.

It’s also not that this project sprung into thin air from a quick prompt and LLM magic… it was driven by a dedicated, highly talented, subject matter expert with extensive SWE background and extensive support from the leading experts in the world. You’ll continue to need someone to steer the ship, even in the Wal-Marts and Targets. An LLM is only ever as good as the input it’s given.

Re: Rewriting Bun in Rust

#195

Post by AlotOfReading »

benced wrote: post #150
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%.

The scary thing is the zig project prohibits LLM contributions - the world is going to move faster than them.

I would be pissed if my programming language changed as quickly as Claude code does. Languages need to move slowly and carefully, and zig is on the faster end of language development regardless.

Re: Rewriting Bun in Rust

#196

Post by pier25 »

atonse wrote: post #170
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…

LTS is more relevant if there was any kind of compatibility that was broken. They still haven’t released 1.4 even though it seems to have gone extremely well by every metric in the wild, with tons of people using Claude code with no regressions in a month. Nothing to me suggests they’re being careless here. In fact, he had two adversarial reviewer Claude instances on every code change, every line. I don’t know a sing…

> LTS is more relevant if there was any kind of compatibility that was broken

Do we know 100% for certain that this isn't the case? No.

In fact it would be naive to think a rewrite of this magnitude wouldn't introduce new bugs and/or unexpected changes in behavior.

> Nothing to me suggests they’re being careless here.

Plenty of reasons suggest this including the lack of an LTS or any kind of thought put into such a massive transition.

Re: Rewriting Bun in Rust

#197

Post by pier25 »

dgacmu wrote: post #153
pier25 wrote: post #144

Earlier quoted context omitted.

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, e…

> Well, the answer is "Anthropic, with claude code"

Anthropic is not exactly the hallmark of engineering excellence... quite the contrary.

> But yes, of course there will be new bugs

Obviously, which is why more thought should have been put into the transition.

Not everyone will want to yolo their production projects into such a massive rewrite overnight.

Re: Rewriting Bun in Rust

#198

Post by smasher164 »

It's still shocking to me that the approach taken wasn't to have Claude write a tool that translates Zig to Rust. I imagine it would've been cheaper, deterministic, and each iteration would produce a better tool.

Re: Rewriting Bun in Rust

#199

Post by galangalalgol »

rvrb wrote: post #171
remexre wrote: post #169

Earlier quoted context omitted.

the point of c++ when you need max perf is to be able to maintain the compile-time abstractions you need w/ templates instead of macros and undocumented optimizer behavior, not oop or raii

you're right that that is a weak argument against C++ in that use case (biased by my own dislike of the language); but it is also a niche that Zig fits into quite well. so it's weird for the OP to claim it's ok to drop down to C++ when needed while kind of suggesting they don't get why anyone would use Zig

If you are willing to hand code intrinsics it doesn't really matter what language you pick from a performance perspective. Rust consistently shows it has better performance than c++ in code that does not hand code intrinsics. If cpu(not gpu) based performance is all you care about there is no reason to pick anything but rust. Modern c++ devs have no trouble with the borrow checker either they are already doing all the things that keep it from complaining. The reasons someone might not pick rust involve integration with existing code, the complexity of the language, and the depth of it's dependency trees. The complexity argument certainly doesn't lean you towards c++ or probably anything with an llvm back end. The openbsd approach to c is probably as simple as you can get these days short of forth or something equally obscure. Dependency trees are deceptive. We all have deeper trees than we think we do, but the rust front end itself has well over 100 crates in its tree...

All that said, I use rust for everything.

Re: Rewriting Bun in Rust

#200

Post by [deleted] »

steveklabnik wrote: post #187
sitzkrieg wrote: post #181

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN