Live data from Hacker News

How is the Bun rewrite in Rust going?

lockwood.dev

161–170 of 412 posts

Re: How is the Bun rewrite in Rust going?

#161
post #26

Earlier quoted context omitted.

They also have made a release, in a sense, since they moved all Claude code users to it a month ago. (And apparently no one noticed). I think they're taking things "gradually" as they are under a lot of scrutiny and no rush for full release.

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.

Claude Code is a large codebase and uses tons of Node’s features either directly or indirectly through dependencies. fetch(), node:http, node:tls, node:os, node:net, node:fs, AbortSignal, node:child_process, node:tty, node:process, node:http2, etc.

Re: How is the Bun rewrite in Rust going?

#162
post #84

Earlier quoted context omitted.

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.

It's the equivalent of porting Unreal Engine 5 to another language and then using it exclusively to run a 2D Tetris clone. Let's wait for the next Bun release when more real-world code is hammering it before declaring victory. (also, fwiw, a manual rewrite would be under the same scrunity and suffer from the same skepticism, at least when obviously rushed).

You have absolutely no way to know this though.

Like, come on already.

Re: How is the Bun rewrite in Rust going?

#163
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…

[flagged]

Re: How is the Bun rewrite in Rust going?

#164
post #98

Earlier quoted context omitted.

How does that help 99.9% of all other companies though?

Some thoughts: - just because it doesn’t help 99.9% of the companies today it doesn’t mean it won’t help them tomorrow - 0.01% of the companies employ a much bigger percentage of people - 99.9% of companies won’t need to do a project of this magnitude

So you think if a company can't spend 1 million USD on a rewrite which has almost zero impact on performance, possibly net negative on maintainability it also can't have 500k LOC codebase either? Oh come on...

Re: How is the Bun rewrite in Rust going?

#165
post #124
post #90

Earlier quoted context omitted.

I think this is perfectly fine. If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era. I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS. A dozen people or so could even run Firefox! I remember (now legend) Terry bothering us to check out LoseThos or GodOS or wh…

> Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished. This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.

> This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.

Almost all of my prototypes are made this way. "I made this in a weekend", is more often, "I made this in a day". Like any trad-coded project, time to vibe code a backend vs frontend time is 1:N

Re: How is the Bun rewrite in Rust going?

#166
post #90

I really do not understand how software developer think anymore. Using a LLM to translate a project in a short time, is by itself incredible. Just like one-shot whatever office clone. But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work. I have used LLMs to create st…

I think this is perfectly fine. If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era. I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS. A dozen people or so could even run Firefox! I remember (now legend) Terry bothering us to check out LoseThos or GodOS or wh…

LoseThOS didn't burn through hundreds of thousands of dollars of expensive and environmentally questionable compute.

Re: How is the Bun rewrite in Rust going?

#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!

Re: How is the Bun rewrite in Rust going?

#168

Earlier quoted context omitted.

This is assuming your engineers don't leave for higher-paying roles elsewhere. The market might be cold generally but for engineers working at these frontier AI companies it's red-hot. And most executives are figuring this into their calculus right now because they were burned badly during COVID. Meta, Google, etc were loose with hiring and engineers flocked from their lower-paying companies in droves. The brain drai…

The job-hopping followed from companies not investing in their engineers, not the other way around. It was billed as the only way to get a promotion (which usually would come every 1-2 years).

I've been in this industry for a few decades at this point and I was around when this meme was started.

It was purely about maxing your compensation because changing jobs nets you more than promotions & raises.

I've never met an engineer in my life who truly earned a promotion every year and very few every two. Very few companies have org charts that even support that or have that many levels. This logic/advice only really applies at a few companies and people have adopted it no matter where they work. There's not enough growth/hiring at 95% of companies to even come close. The Peter Principle is also a real thing. Everyone's competence has a ceiling.

There's even an implicit understanding of this that people at smaller companies have inflated titles and you typically rank them down 1-2 levels when hiring/acquiring at larger companies.

Now I do agree that companies haven't been investing in their engineers, but that doesn't also mean this isn't a vicious cycle. Employers and employees are in a mexican standoff and things are only going to get worse until one side comes to its senses. Employers have all the leverage for it to not be them.

For the vast majority of companies the average tenure of an engineer sits between 18 and 30 months. They're also mostly hiring young engineers in their 20s. As an employer what is your upside to making such investments before they're at least mid-career? A lot of people seem to want the world and offer nothing in return for it.

Re: How is the Bun rewrite in Rust going?

#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

Post reply on HN