Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Claude Code uses Bun written in Rust now

simonwillison.net

Post reply on HN
Print view View original

411–420 of 920 posts

Re: Claude Code uses Bun written in Rust now

#411

Post by vips7L »

onetrickwolf wrote: post #381
weakfish wrote: post #212

Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript” The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO. If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

> why not rewrite CC in a native language? It's hell to maintain for not much gain (for a use case like this at least). As much as it's become a meme, JS and web tech in general has become extremely portable and stable. I also don't think Anthropic bought bun to make their TUI better. They could have forked it, they bought bun because it incidentally was excellent for the way agents prefer to work and they wanted to…

I thought maintenance was free with LLMs???

Re: Claude Code uses Bun written in Rust now

#412

Post by vmg12 »

wild_egg wrote: post #394
vmg12 wrote: post #323

Earlier quoted context omitted.

The fundamental problem with all Js based apps is how they are very single threaded. With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude C…

No, the fundamental problem of these apps is that they are, for no reason, pretending they need a high powered game engine rendering loop. They don't. It's a text printout of history with some hotkeys for mode switches and such. "rendering in a single thread" should never be an issue because it should never be "rendering". It needs to stream text to stdout. That's been a solved problem for 50 years and now it takes 2…

Drawing to the terminal / rendering / whatever, this is all arguing semantics and very uninteresting and not insightful.

> they need a high powered game engine rendering loop

Don't believe the bs on twitter. Claude code source was leaked, there is no high powered game engine rendering loop.

> It needs to stream text to stdout

These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. If the work was split across threads they would not use anywhere close to as much power and there would not be a slow ui.

If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.

The reason the computer gets hot and uses more power is because the cpu is getting close to 100% utilization.

Re: Claude Code uses Bun written in Rust now

#413

Post by mrothroc »

latortuga wrote: post #400
mrothroc wrote: post #372

Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust. Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people miss…

I seem to recall this Rust rewrite is all "unsafe" meaning it really doesn't automatically eliminate those issues.

Relevant passage from Jarred's post:

"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."

Re: Claude Code uses Bun written in Rust now

#414

Post by rekttrader »

They’re just wildly successful terrible engineers who can describe problems well and have unlimited token budgets. If they were paying for their own token use, the software would be better, they simply don’t have financial incentive to be more performant.

A dirty secret of AI data centers are that they’re only getting 40-60% efficiency out of their GPU clusters and because the moneygun go brrrrr they just buy more.

You wonder why they’re so afraid of the Chinese competition… they can’t afford to be as wasteful

Re: Claude Code uses Bun written in Rust now

#415

Post by vips7L »

Philip-J-Fry wrote: post #387
Aeveus wrote: post #175

Anecdotal, but I’ve been getting segfaults in Claude Code. I run inside Kitty tabs, and the entire tab becomes unusable when this happens. No response to inputs at all from that point. When this happens, a link shows up to report the issue. It’s not clickable (likely due to the segfault), and perhaps more important: it’s encoded, so you can’t see what you would be sending in your report. Hope it gets better.

Segfaults were a thing with the Zig version. Purely based on the fact it's a line by line translation of the Zig code to unsafe Rust, all the Zig code that caused segfaults is going to also cause segfaults in the Rust version. The Rust code won't fix it until they get to the point of refactoring it into idiomatic and memory safe Rust.

But if the segfaults are new that implies it’s from the LLM no?

Re: Claude Code uses Bun written in Rust now

#417

Post by sensanaty »

simonw wrote: post #368
sensanaty wrote: post #330

Earlier quoted context omitted.

[flagged]

I've not made any money at all from Anthropic. You can see my list of previous weekly blog sponsors here: https://simonwillison.net/dashboard/sponsor-history/ None of them get any influence on my content. That would hurt my credibility, and my credibility is the reason my site is worth sponsoring in the first place. Honestly, if OpenAI or Anthropic offered to sponsor I'd probably turn them down. The optics of taking…

Fair, that rules out "Anthropic pays you directly."

But look at your own disclosure page [0]: OpenAI paid you for your time at a GPT-5 preview, and you regularly get early access, embargoed previews, and free API credits from OpenAI, Anthropic, Gemini, and Mistral. So "I've made no money from Anthropic" is narrower than it sounds, access and preferential treatment are compensation too, even if cash didn't directly change hands.

Same goes for the sponsor list. Microsoft is OpenAI's investor and infrastructure (or was anyways, I've got no clue what the status of that is these days), Amazon and Google are both major Anthropic investors, and most of that list runs on Azure, AWS, or GCP, or sells tools built on these labs' models. Taking a Microsoft sponsorship isn't really separate from an OpenAI one, it's just a single hop removed. The entire software ecosystem and all the players in it are entangled in this bubble.

I'm not accusing you of consciously hyping any of them. Your posts are high quality even when I disagree with the contents of them. You often list downsides too, prompt injection, security, slop issues but the throughline still repeats: this is inevitable, get on board. Product-market fit found, November 2025 as the inflection point. That kinda framing shows up again and again throughout all your posts.

It's refreshing that you're upfront about the previews and credits and all that jazz, but surely you understand why some people stay skeptical even with that disclosed as it confirms the access exists.

Whether you realize it or not, I think they are indeed paying you in some sense, which is part of why I'm skeptical when your posts consistently land at the top of HN. Not because the writing isn't good, but because I think the same incentive shaping the coverage probably shapes some of that reach too.

[0] https://simonwillison.net/about/#disclosures:~:text=2024%2E-...

Re: Claude Code uses Bun written in Rust now

#418

Post by jchw »

weakfish wrote: post #212

Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript” The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO. If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

Yknow, I really didn't mind Claude Code that badly, but subjectively speaking I really do like Codex more after using it for a couple weeks. Feels a bit snappier and lighter weight. I know with OpenAI you can actually use third party tools with the subscription so there's less of a draw to using Codex, but I still find myself preferring it now.

Is this because Codex is written in Rust and not JS? I dunno. I think it's more just "lighter" in general, or it certainly feels that way. It's probably possible to make something with a similar feel in JS, just perhaps not with the big honking mess they've created.

Re: Claude Code uses Bun written in Rust now

#419

Post by [deleted] »

weakfish wrote: post #212

Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript” The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO. If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

[deleted]

Re: Claude Code uses Bun written in Rust now

#420

Post by troupo »

benoau wrote: post #273
tripleee wrote: post #256

Earlier quoted context omitted.

They succeeded in spite of their tech choices. Their model outshone it, which is an extremely rare thing to happen and not something they could've counted on. In any other timeline they could've/would've been hurt by their choices. It's like "why did you go all in on buying scamcoin 3.0 as your investment strategy?" -- "I 5xed my money! End of story! It was fine!"

> They succeeded in spite of their tech choices. Or those choices just don't matter, it's fundamentally just "tabs vs spaces".

A TUI outputting nothing but text shouldn't consume 70 GB RAM and yet there they were just half a year ago: https://x.com/jarredsumner/status/2026497606575398987

They couldn't even fix flickering in their TUI and their new renderer is complete garbage.

They succeeded despite their tech.

Post reply on HN