Live data from Hacker News

How is the Bun rewrite in Rust going?

lockwood.dev

181–190 of 412 posts

Re: How is the Bun rewrite in Rust going?

#181

Earlier quoted context omitted.

I thought it was a fairly common turn of phrase! https://blog.codinghorror.com/the-project-postmortem/

A postmortem is for reflecting on something that went so wrong you had to kill it, and you want to objectively describe what led to that, and what lessons can be learnt from the failure. A retrospective is just the reflecting part, without implying you believe it is going to fail and you're looking for some schadenfreude ;)

From the article:

> The goal of a postmortem is to draw meaningful conclusions to help you learn from your past successes and failures. Despite its grim-sounding name, a postmortem can be an extremely productive method of improving your development practices.

Re: How is the Bun rewrite in Rust going?

#182
post #175
post #148

Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall. In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likel…

Any comment on the costs estimated in the article? especially the buildkite costs?

CI has always been expensive for Bun including before the acquisition. We build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64] and then run tests on multiple Linux distros with multiple shards, multiple macOS versions and Windows for each architecture.

We recently started cross-compiling all the builds on Linux arm64 and that made it a little faster (I wrote a CLI tool to download the correct macOS headers for cross-compilation). We also have a daily cron job that asks claude to make the slowest tests faster while adding more assertions.

Re: How is the Bun rewrite in Rust going?

#183
post #180
post #169

One metric I thought might be interesting with respect to the Rust rewrite is the number of "unsafe" occurrences in the code. I was optimistic those would be going down over time but it looks like they've stayed pretty constant: https://news.ycombinator.com/item?id=48966569#48967630

Does that data exclude FFI wrappers, which necessarily must be unsafe? If not, don’t put much stock in it.

No, it's a raw count.

I get that there's a baseline of unsafe that's necessary, but I was under the impression that some of those unsafes were in places where they could be replaced by more idiomatic Rust at a later date.

Re: How is the Bun rewrite in Rust going?

#184
post #127

Earlier quoted context omitted.

because their js code is so bad and slow that they need the bun performance hacks and optimisations.

Do these hacks make bun less secure than other runtimes? I find it a little hard to believe you can get much more robust and performant than V8 or SpiderMonkey without cutting some corners that notably went uncut by either for all these years.

yes, especially compared to deno bun does not have proper isolation or permissions at runtime layer which is why anthropic tries to fix the lack by a mixture of app layer (build into claude code) and os layer (srt) however using runtime permissions would allow much better security if done right.

Re: How is the Bun rewrite in Rust going?

#185

Earlier quoted context omitted.

If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust? That likely would be far more efficient than changing the language of your typescript runtime that ships to run your react-based CLI app. I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.

> If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust Rewriting a runtime with well-defined interfaces and behavior is quite different from rewriting a user-facing application under active development by a decent chunk of their organization.

I agree, but this difference is very frustratingly omitted from the hype-sphere surrounding the rewrite, even though most software developers don't work on a runtime with well-defined interfaces and behavior. I know a number of people who've developed severe FOMO that their projects take longer than 2 weeks and maybe it's because they're not AI native enough.

(I don't mean to be critical of the Bun maintainers, who have always been open about the fact that they leveraged the specific context of their project to do this effectively.)

Re: How is the Bun rewrite in Rust going?

#186
post #84

Earlier quoted context omitted.

Claude Code most likely only uses a tiny fraction of Bun/Node features, so Claude Code switching to the Rust rewrite doesn't mean all that much.

Look, I understand being skeptical of the whole process; the discourse about this has been extremely tiring. But at some point if “moving one of the biggest actively maintained and used codebases to it without anyone noticing” is dismissed as “it doesn’t mean all that much”, then we’ve lost the plot a little bit somewhere.

Why is porting a program from one language to another seen as some great achievement? We had f2c in the 1990s.

https://en.wikipedia.org/wiki/F2c

Re: How is the Bun rewrite in Rust going?

#187
post #183
post #180

Earlier quoted context omitted.

Does that data exclude FFI wrappers, which necessarily must be unsafe? If not, don’t put much stock in it.

No, it's a raw count. I get that there's a baseline of unsafe that's necessary, but I was under the impression that some of those unsafes were in places where they could be replaced by more idiomatic Rust at a later date.

I don't think that's true. I think a fair chunk of them are places where Bun is handed a pointer by WebKit or something similar. I believe they write about this a little.

Re: How is the Bun rewrite in Rust going?

#188
post #65

I am fascinated by the discourse around this Bun rewrite. I read a lot of drama and personal accusations, there are pieces like this one trying to extract clues, and it seems everyone has a deeper ideological concern behind whatever they are trying to say. For this article, it seems to be skepticism towards AI and how successful it can be at replacing programmers. Other takes, like the one from the Zig maintainer, we…

> experienced devs

No one on their team had Rust experience

Re: How is the Bun rewrite in Rust going?

#189

Earlier quoted context omitted.

I thought it was a fairly common turn of phrase! https://blog.codinghorror.com/the-project-postmortem/

A postmortem is for reflecting on something that went so wrong you had to kill it, and you want to objectively describe what led to that, and what lessons can be learnt from the failure. A retrospective is just the reflecting part, without implying you believe it is going to fail and you're looking for some schadenfreude ;)

This might be terminology that's used differently in different places. For instance, in video games it is extremely common to use "postmortem" to mean "post-shipping."

Example: https://blog.codinghorror.com/game-development-postmortems/ Note the dual emphasis on both "what went right" and "what went wrong," not just one or the other.

Re: How is the Bun rewrite in Rust going?

#190
post #167

This article could increase its credibility by being updated to acknowledge that Bun-on-Rust has been live in Claude Code itself since June 17th, and available as a canary release since it landed on main. Rewrites of this scale certainly justify long canary release periods!

I mention Anthropic dogfooding this in the article.
Post reply on HN