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

461–470 of 920 posts

Re: Claude Code uses Bun written in Rust now

#461

Post by api »

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.

Lots of devs know how to code in it, and the AI models have more training in JavaScript than any other language.

It's like asking "why does everything run on Windows?" Because everything runs on Windows.

Re: Claude Code uses Bun written in Rust now

#462

Post by wild_egg »

vmg12 wrote: post #412
wild_egg wrote: post #394

Earlier quoted context omitted.

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 highlightin…

There are two different arguments here.

> These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown.

The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want them and would appreciate a way to disable all of that to reduce CPU use.

Re: Claude Code uses Bun written in Rust now

#463

Post by amluto »

jchw wrote: post #418
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'…

Codex appears to be a mildly complex, somewhat-but-not-outrageously-sloppy Rust program (yes, I’ve poked around at its source — thank you OpenAI for making it more or less open source). It has lots of features, mostly related all the fancy web features of Codex.

Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.

Re: Claude Code uses Bun written in Rust now

#464

Post by piker »

squidbeak wrote: post #459
piker wrote: post #453

Earlier quoted context omitted.

Right now? Zero. In 2 years? A well-engineered TUI could be the difference between the Blackberry and the iPhone for all we know.

Perhaps over those two years they'll reach the same conclusion and change the engineering?

Perhaps.

Re: Claude Code uses Bun written in Rust now

#465

Post by yoyohello13 »

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 is kind of mind boggling. They could have chosen anything and decided to implement it in the slowest jankiest way possible.

Proves LLMs don’t help with taste.

Re: Claude Code uses Bun written in Rust now

#466

Post by nnmg »

vmg12 wrote: post #412
wild_egg wrote: post #394

Earlier quoted context omitted.

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 highlightin…

I don't think any of that seriously counts as real work.

Casey Muratori addressed this years ago with the windows terminal drama, https://github.com/cmuratori/refterm

Re: Claude Code uses Bun written in Rust now

#467

Post by hluska »

coldtea wrote: post #377
pdimitar wrote: post #342

Earlier quoted context omitted.

> But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically. This is a spectrum, it's not just 0% vs 100%. Even Fable frakked up a few things really badly in my professional work (though to its credit after a very detailed 2h chat it self-corrected and fixed all the blunders). I would…

> Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k. For an entity like Anthropic that's not even the cost of a single developer for a year. It's closer to what they pay a chef on premises. That the showstopper for a better Claude agent is that they'd need to pay $168k or event $1M or even $10M in cost…

Do you know their entire roadmap? If not, maybe different people prioritize things differently when they see their full strategic position.

Re: Claude Code uses Bun written in Rust now

#468

Post by solid_fuel »

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…

> It largely works and it's a massive business success.

You can make anything work when you have enough money to buy and radically change the entire runtime you’re relying on.

One must suspect that if they did not have insane amounts of money to burn, they could have tried other approaches to fixing the problems. Maybe engineering, perhaps.

Re: Claude Code uses Bun written in Rust now

#469

Post by fleventynine »

Tadpole9181 wrote: post #366
ambicapter wrote: post #259

Earlier quoted context omitted.

What's the point of rewriting it to Rust if you're going to, on purpose, disable the most prominent benefits of using Rust?

It isn't disabled, it has exclusions. Now that they have it, they can close the gaps. It was literally impossible to have ANY coverage before, now they are mostly , covered and have an avenue for remediation. I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good? Was nobody here for moving billions of lines of JavaSc…

I like Rust and use it full-time professionally. Unsafe is not the same as unsound. Unsound means that the unsafe code is not maintaining the aliasing invariants on references required by the language, and thus undefined behavior can leak into safe code (that is, the safe code can be miscompiled).

Known unsound code should not be merged, let alone released to production. If you have good enough tests and run them under MIRI or ASAN, maybe you can get away with it for a time, but most Rust experts would not sign-off on such a project.

If somebody put a gun to my head and told me to make the best of such a codebase, I would try to figure out how to turn off the LLVM optimizations that assume the Rust references don't alias. With these optimizations this codebase is scarier than most C or C++ code.

Re: Claude Code uses Bun written in Rust now

#470

Post by lunar_mycroft »

endospore wrote: post #234
Tadpole9181 wrote: post #217

Earlier quoted context omitted.

This feels like such an absurd, bad faith take I keep hearing. In Zig, every single memory operation is unsafe. And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors. There's too much, sure, but can we at least be honest and reasonable?

My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it) > must interface with C code that has no safe interface Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2…

> Deno for instance have ~0.2x as many unsafes.

Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code).

Post reply on HN