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

391–400 of 920 posts

Re: Claude Code uses Bun written in Rust now

#391

Post by groundzeros2015 »

switz wrote: post #236
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.

It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture. Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rig…

As an industry we are responsible for making our part good. So yes a business can succeed in spite of bad tech choices, but that doesn’t make it good tech.

Re: Claude Code uses Bun written in Rust now

#392

Post by groundzeros2015 »

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

Apply this reasoning to any other industry. Yes the average person is not the judge of the quality of a doctor or engineer. That doesn’t invalidate it. You want a doctor who cares about medicine , not whatever will accomplish a business goal.

Re: Claude Code uses Bun written in Rust now

#393

Post by reinitctxoffset »

switz wrote: post #236
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.

It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question. They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture. Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rig…

I think it makes sense that when you've outlawed competition for many/most users of your product's matching service that you would cheap out on it if you were maximally extractive and took no pride in your work, sure.

But the "coding is mostly solved" narrative kinda doesn't match right? If good, correct, high-performance software is like, free now? Wouldn't you want it to be slick as hell, really reliable, all that? Even a little breakage costs a lot of money at that scale and pricing, it would be better than a wash if you put the magic code thing on the case.

"Claude. Do all employee work. Make no mistake. Notify in slack when revenue is double."

Re: Claude Code uses Bun written in Rust now

#394

Post by wild_egg »

vmg12 wrote: post #323
ljm wrote: post #223

Earlier quoted context omitted.

I never knew that running an interactive program in my terminal would absolutely rinse my CPU and battery but that's what Claude, OpenCode and Ghostty have colluded to achieve. Even when the laptop is asleep overnight it's practically melting. I'm sure there was some logical reason for shoehorning web technology into this stack given that we have a good 40 years or so of experience with interactive terminal programs…

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 2GB of memory to be done poorly with broken scrollback.

Re: Claude Code uses Bun written in Rust now

#395

Post by mrothroc »

awesan wrote: post #376
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…

Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things". You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (…

[dead]

Re: Claude Code uses Bun written in Rust now

#396

Post by tripleee »

anamexis wrote: post #276
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!"

What do you mean in spite of their tech choices? When have the tech choices ever been an issue in the lifespan of Claude Code? From where I sit, it seems like their tech choices enabled them to create an industry-defining product.

I mean people are using Claude Code because of their underlying LLM - they'll put up with Claude Code. There's no other real option to get Opus at a reasonably affordable price without CC.

Most people would choose to swim a lap through a pool of pee to get a billion dollars at the end. The pool of pee itself wasn't the once in a lifetime opportunity (for most).

Sorry, I'm bad at analogies.

Re: Claude Code uses Bun written in Rust now

#397

Post by K0nserv »

dnautics wrote: post #337
K0nserv wrote: post #235

Earlier quoted context omitted.

> There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of t…

yeah rust has no footguns. just dont try to mix clone with iter.

Of course Rust has a few footguns too, that's not my point.

Re: Claude Code uses Bun written in Rust now

#398

Post by groundzeros2015 »

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.

The answer is those are the tools their lead engineers knew, so they repurposed them rather than learning other paradigms .

Re: Claude Code uses Bun written in Rust now

#399

Post by K0nserv »

skydhash wrote: post #293
K0nserv wrote: post #235

Earlier quoted context omitted.

> There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of t…

There are many things in life that are "fine" only when you take extreme care (knives, cars, industrial machinery,...). The thing is something like C has many usages and you can't just say "use Rust" and be done with it. Using Rust is not cost-free.

I'm not saying "never use C". The thing I dislike is the false dichotomy between "(Zig|C|Go) is simple unlike Rust, which is complex". A statement like that makes it sound like writing correct code in the former is easier when it's, in fact harder.

Re: Claude Code uses Bun written in Rust now

#400

Post by latortuga »

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.
Post reply on HN