Hacker News new | ask | show | jobs
by Jarred 2 days ago
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 likely next Tuesday we’ll do the release of 1.4.

11 comments

Take as long as you need to ensure software quality. A month without a release isn't a big deal and whomever needs a specific feature can offer to contribute or build themselves.

Node has 4-6 weeks without a meaningful release (other than security stuff) pretty much every December. I think the criticism in the article is unfounded and whomever needed/wanted a release should have asked first instead of writing an "angry" blog post.

(I'm a Node.js maintainer)

What is Node getting every 4-6 weeks that makes it noteworthy when it doesn't?
Text imports (experimental), native addon ESM support, blob textStream(), ReadableStreamTee, byob for readFile, better event loop monitoring and lots of security fixes as well as more minor bug fixes and improvements. (Last 4-6 weeks)
Another functional way to iterate over an array
Author here: I don't need or want another Bun release or an NPM release or anything like that. Like I very clearly say in the article I just got chatting with a peer about the Bun rewrite and I decided to take a look.

I'm consistently skeptical about new tech whether it is NoSQL or Blockchain or Serverless. Some of the things I'm skeptical about fail and some succeed.

That’s a great approach. No matter what you will always find a reason to be positively surprised!
The bun Port is a phenomenal engineering achievement that would have taken a team of people over a year or two to deliver previously - look at the TypeScript port for example (and they had llms).

The fact it's taking a while to release is still insanely fast. I'm sure they may be some bumps.

Being skeptical is good and some stuff succeeds and some doesn't - but building tools is still fun and cool, whether it's useful or widely adopted or not :)

The initial "10 days and $165k" was still a tad optimistic dontchathink?
Yeah if you want you can check out my github page to see some tool failures. Nobody is hyping those up, though.
The problem is what you’re skeptical about, the true cost, is probably the least important part.

Did it really cost $1 million instead of the 150k that’s been floating around?

If you don’t like the price now just give it some time.

The point is that these kind of heroics can actually work now and they’re only going to get cheaper.

I don’t mean to sound negative about what you wrote, it was an interesting read.

Personally I think the cost does matter.
What are some of your favorite tools or services that you adopted in the past few years?
uv
That's not surprising. Claude code is buggy enough, and releases break things often enough, that I wouldn't expect users to distinguish bugs introduced by switching to rust-based-bun from the normal garden variety bugs.
I can count the number of times an @ file reference doesn't autocomplete on a hundred hands. Or how a rewind won't reset the "is this file Read" marker. Or how a Branch (forking a convo) takes literally 5+secs to run. Or how a slashcommand that's user-only will not work if its in the middle of a prompt. Or how ctrl-r search will match results that don't include any search terms. Or how you can't resume a branch given its session id.

Yes Boris, tell me more about how "coding is solved".

Edit: literally just now, while writing a claude code hook, opus5 gave me this LOC because apparently the changelog and what's in the transcripts _differs_; great docs d00ds.

    # Present only for a subagent's calls. Both spellings accepted: the changelog
    # names `agent_id`, transcripts use `agentId`, and we need not care which lands.
    agent=$(printf '%s' "$input" | jq -r '.agent_id // .agentId // empty')
Claude Code is quite buggy but doesn't generally crash, which is what you would expect if it shipped an immature backend for a month. Maybe the rewrite is full of bugs and they happened to result in the UI glitches or trashed settings files or whatever other application-level bugs that Claude Code has routinely rather than crashes but that would be pretty surprising.
I’ve come to just expect that my CC instance will randomly “blank” and that I have to resize my terminal / use page up/page down to get it to show again.

Supposedly they used a game engine to render their TUI but I’ve never had an FPS game do that.

They drive the TUI from the same thread that actual does stuff.. causing frequent freezes.

No GUI developer would ever put this on the same thread.

Just ask Claude to fix it, what’s the problem??????? /s
"Claude did implement multithreading in JS but we don't want to mantain a fork of WebKit" - jared apparently
Ok, so you've just admitted that you have deployed thousands of lines of likely non-human reviewed LLM generated code (Bun's rust rewrite) to millions of client machines (via the Claude Code app auto-update) with significant local client access credentials, in a relatively quick and rushed manner.

What's stopping the LLM from having unscrupulously injected something nefarious into the codebase that you are unaware of?

What's stopping future updates from the LLM from doing the same?

Are you aware of the potential ramifications of deploying thousands of lines of non-human reviewed code to millions of users machines?

Are you happy to be personally responsible for the horrendous outcomes that could occur in these situations?

Claude Code has been written with Claude Code for a long time - that ship has long sailed.
Is that why Claude Code is buggy as hell?
Apparently it isn't good enough to generate native clients though, like many humans everything is Web tech.
I would be stunned if there was a single line of hand written code in the entirety of Claude code lmao. Or if more than 20% of the code had been read by a person at any point. Why would you expect your ai code harness to not dogfood?
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I guess they put it in capitals for a reason.

"I put it in the terms of use, so I am not responsible for what my poorly developer software does" only goes so far.

It could be argued, probably successfully, that this is a case of gross negligence and that Anthropic should be held accountable for harm caused due to their reckless actions.

Especially now that they have been made aware of the possibility, they also cannot claim ignorance of the potential issues.

Certain consumer rights, depending upon the country, also cannot simply be removed or waived due to a organisation's terms of use or implied contract.

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.

I think the question for CI costs is still out there. While I do not think it should be in tunes of thousands a day but thats the skepticism presented in the article. True costs are really important to make a good decision in situations like this. One has to consider the fact that lots of people are going to use these numbers to justify the rewrite in future.
How come Bun uses Buildkite instead of self-hosting the CI infra?
It spawns ephemeral EC2/Azure instances, which is a lot cheaper than the GitHub actions runners we used before that.

We shard to a lot of machines for tests and I’d be worried about running out if we used dedicated servers.

BuildKite is fine but I wouldn’t be that surprised if we move off of BuildKite to a custom thing at some point. Months ago, we switched from CMake to a handrolled typescript build system and it made our builds faster and simpler.

Thanks for answering!

I suppose my second question would be how much Bun spends on CI per month atm - I'd imagine that robobun would have ramped up the bill a fair bit

you don't need buildkite or blacksmith anymore.

codex trivially built me a self-hosted gh actions runner workflow for ephemeral vm's (just a big bash script that manages the vms with qemu). i even sped up the builds with my own custom base image with everything installed in it that i need too.

it works flawlessly.

fanning that out to starting and stopping instances wouldn't be too much of a stretch.

Does it work with macOS ?
Presumably because they "build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64]" and self hosting all of that would be time-consuming and expensive.
Probably because they don't want to self-host Windows or MacOS servers when they can pay someone else to do that for them (or Linux ones, I assume that is within their wheelhouse for production but CI is a bit of a different beast to model inference).
So are the "$800k + CI" estimates accurate? And your team works weekends just to make tests faster?
In Dutch there's a saying, "wij van wc eend adviseren wc eend", and it fits perfectly.
I don't see how it does. Claude Code is an extremely widely used product; the preceding comment offered an objective evaluation target, not a "trust me it's good" argument.
I don't see how Claude code being a widely used product is relevant to the person who orchestrated the Rust rewrite of bun saying that the orchestration of the Rust rewrite of bun went well. Wc eend is a widely used product as well, if that helps.

Ah, for context, which I suspect you may be unaware of, Jarred (the person who said the rewrite to rust went well) is the creator of bun, and the guy behind the rewrite.

I think the chain of reasoning is not hard to follow:

1. Assume the Rust rewrite of Bun went badly

2. Then something must be grievously wrong with a released bun runtime based on that code

3. Claude Code uses the released bun runtime based on that code

4. From #2 and #3, something must be grievously wrong with Claude Code

5. If something were grievously wrong with Claude Code, users would reduce use of Claude Code and use alternative tools

6. From #4 and #5, users are reducing use of Claude Code and using alternative tools

7. Claude Code has wide use and use is growing across all software engineering verticals

8. #6 and #7 contradict

9. From the contradiction, the assumption in #1 is false

The parts that are not explicitly spelled out here are an exercise for the reader. It doesn't really matter if the guy who wrote Bun said this or my uncle said this.

Ok, thanks for explaining! Doesn't really explain how the wc eend expression _doesn't_ apply here (which would be hard to do, because it _does_ apply, since this is someone praising their own work, and it doesn't get more straightforwardly applicable than that), but I do really appreciate the effort.

I always thought it was common sense and just basic critical thinking to take people paid by Anthropic praising products of Anthropic with a grain of salt (and let's be clear, that's what this is), but apparently it's not.

Frenchman here, I Google Translated that and it says

"We at WC Duck recommend WC Duck"... I'm left scratching my head, if you'd care to spell out what the saying means for non-Dutch I'd appreciate it :)

It was a commercial slogan for a toilet cleaning agent. An English equivalent would be "mr clean recommends you use mr clean". Today, it is used to point out when someone tells you they themselves delivered good work. Anytime you'd use the meme of Obama giving himself a medal, you could use this phrase.
The Toilet Duck brand exists in English. Canard-WC in French, even.
Actually the existence of the French name is confusing for English speakers as although many would know enough school French to get "canard" == "duck" if prompted, in English this word ends up meaning some sort of fabrication or hoax, apparently from an old French joke where somehow that punchline of that joke was popularized in England so long ago we don't have records. Human culture is weird.

So the first thing an English native might get from "Canard WC" is probably hoax toilet, I expect the duck imagery of the product would bring the "canard" == "duck" meaning across though.

I probably should have figured part of it out from my basic German, but I guess the Dutch don't capitalise nouns?
Any chance for 1.3.15 with bugfixes for the rest of us?
They declared bankruptcy on the original code base so hard that they decided to chuck it all in the trash. I wouldn't hold my breath expecting support for their existing users.
Yeah, 1.3.14 has some bad regressions. 1.3.11 is ideal for tests CI. Or canary. For production, I don’t have any advice. There will be no 1.3.15.
Jarred thank you for doing the impossible over and over. Bun is such a fun thing to use after years of npm. Good luck with your quests! Have fun
If actually anyone noticed, then it is a pretty bad move. Also “going well overall “ does not answer the author’s observations either.
We would need to know at least:

- How many people have updated Claude/Bun to the latest version.

- How many subscribers care about reporting issues. Most of them are forced to use the tool against their will and have mentally checked out already. Why report issues if your employer values slop code anyway. Just log the hours and keep your head down. Maybe it is not expedient for the AI narrative to report issues!

- How many subscriptions are real vs. bulk distiller accounts.

- If subscriber numbers are inflated.

Judging by the weird Claude Code Github issues page, there are suspiciously few new issues: about 2 to 3 a day only vs. alleged subscriber numbers of 4 million.

> How many people have updated Claude/Bun to the latest version

By default, Claude Code updates itself all the time without asking for permission, so I'd say most users are on the latest versions.

I do not trust AI agents to run outside sandbox and use them only in dev container. I always use latest version available when I build container (once or twice a month). In my opinion it is to risky to allow auto update for SW which is released several times a week including weekends and is capable of/willing to do script kiddie pranks :-)
Well, OK, you do that. Many others don't. Not sure what your comment adds except saying "not everybody allows audo-update" which is IMO redundant and obvious.
I noticed, I started getting memory leaks suddenly and it restarted the process in long sessions because of limitation of environment limit.
Jarred, thank you for working on Bun. Many "vibe coded" :D projects start strong and are later abandoned (like potentially Anthropic C), so I understand why people worry about Bun's future. I hope Bun lasts for many years, like GCC. Bun is fast and great to use.
Anthropic's C compiler was a proof of concept[1], so it makes sense that it was abandoned.

[1] What it actually proved is up for debate.

The issue is that the Claude's C Compiler repository does not explicitly identify the project as a proof of concept. It was largely produced by one person directing Claude, and Bun's Rust rewrite also seems to have been driven by roughly one person using Claude Code. That similarity is what worries me. Bun's rewrite could also turn out to be proof of concept.
> What it actually proved is up for debate.

I guess I'm debating, but it seemed clear enough to me? It proved that AI models and their harnesses are to the point where you can give them some work to do and leave them unattended for a long time, and they'll keep doing productive work for quite a while. This was a novel thing, and quite unclear, at the time the experiment was performed.

Obviously, the word "productive" is doing a lot of work there, but in my understanding the intention was nowhere near "commercially viable" or "practically useful", it was more like "not doing stupid shit like writing comments of the form 'This file contains the implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation ...'".

Maybe somewhere in the vicinity of "either passing more tests or generating more valid tests"?