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

451–460 of 920 posts

Re: Claude Code uses Bun written in Rust now

#451

Post by raincole »

conartist6 wrote: post #76
gabrieledarrigo wrote: post #14

Bah. Personally my take on the entire affair is quite negative, whatever Jarred or Simonw says about it. I think Bun owned by Anthropic and the entire rewrite with AI is not the real point (even if it's quite interesting, though). My take is that Jarred, and Bun,didn't demonstrate a serious, adult approach, from "this is my branch, you are overreacting" message to just proceeding with a 1mil+ PR merged in less than m…

Haha TS7 is the next biggest example of, "Let's just do a line by line port to another language instead of seriously examining our architecture"

This is the correct approach (I dare to say the only correct approach) when porting to another language. You can examining the architecture later.

Re: Claude Code uses Bun written in Rust now

#452

Post by hugmynutus »

jstimpfle wrote: post #432
hugmynutus wrote: post #425

Earlier quoted context omitted.

This reads like cope because you're re-inventing RAII from first principles. I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd. That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with t…

I've argued elsewhere some things that are wrong with RAII and C++ objects in general. Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story. To deconstruct a pool of objects, I don't see what should e…

> I don't see what should ever be wrong with a function pointer. [...]Care to explain what's the issue here?

1. You're writing code you don't have to

2. That adds runtime overhead

3. That when you screw up has non-trivial security & resource management side effects

This is objectively indefeasible in nearly any vaguely professional context.

Re: Claude Code uses Bun written in Rust now

#453

Post by piker »

madeofpalk wrote: post #447
coldtea wrote: post #295

Earlier quoted context omitted.

> 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. Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack. 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 w…

How much extra money do you think they would make if Claude Code wasn’t JavaScript?

Right now? Zero.

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

Re: Claude Code uses Bun written in Rust now

#454

Post by eventhorizon77 »

ethbr1 wrote: post #192
conartist6 wrote: post #162

Earlier quoted context omitted.

Don't forget the group asking really dumb pointless questions like "who legally owns the rewritten code"

Afaik, under current US law (Thaler v. Perlmutter 2025^), "the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being". With regards to AI-generated code, this means the copyrightability (at all , not with regard to who owns it) turns on whether or not a human was substantially involved in its creation. Existing decisions require evidence of pretty heavy and continued h…

Couldn't it be argued that Bun-Rust is still MIT licensed, because the old implementation was "in the first instance" authored by a human? All the machine did was translate it.

I think it's the "infringing usage" question that is more interesting. If the LLM trained on GPL-derived code, what does that mean for the end result?

Re: Claude Code uses Bun written in Rust now

#455

Post by miroljub »

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.

> 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”

No, you are not crazy. They do crazy things with unlimited budget, and still their chat app flickers when using.

They should just port pi-tui from pi coding agent, since they have no clue.

Re: Claude Code uses Bun written in Rust now

#456

Post by anematode »

slekker wrote: post #163
nirui wrote: post #141

All the emotion of speculations aside, how it runs? It boots faster yeah, but what about RAM and CPU usage? Weird dead loop or dead locks? If it run as good as before or even better, then that's kinda impressive. I'm a developer so I really don't like it when AI might took my job, but if everyone on this planet could create a software for themselves exactly as how they wanted with just a few simple demands, that will…

> Think of it as a democratization of technology Incredibly naive take when these models are closed behind (for now subsidized) paywalls. This "democratization" argument is so nauseating, seems like the Bun port to Rust as a marketing piece (the primary motivator) sold it well!

It's a "democracy", in which some people (Anthropic and co., and anyone willing to suck up to them) are more equal than others...

Re: Claude Code uses Bun written in Rust now

#457

Post by BigTTYGothGF »

pjmlp wrote: post #326
bitwize wrote: post #201

Earlier quoted context omitted.

Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are: > Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage. https://x.com/typememetics/status/…

There is more to it even, the UNIX and C founders arrived to Go, before retirement, after a few other interactions. AT&T was the one doing the Cyclone research. And then we have a bunch of folks assuming they know better about C that its own authors?

> And then we have a bunch of folks assuming they know better about C that its own authors?

Barthes aside, C's changed a lot in the years since they left.

Re: Claude Code uses Bun written in Rust now

#458

Post by anematode »

PsylentKnight wrote: post #161
codethief wrote: post #103

Incidentally, Claude Code has been very buggy for me lately (much more so than before). Lots of TUI rendering issues causing, e.g., the conversation history to be garbled etc.

Every time I resize my window now, the output is completely garbled. I often have to ask it to repeat itself just so I can see what it just said. This isn’t a new thing, but it feels like it’s gotten worse. This is on Windows

Same observation. One thing you can do is close out the session and `claude --resume`

Re: Claude Code uses Bun written in Rust now

#459

Post by squidbeak »

piker wrote: post #453
madeofpalk wrote: post #447

Earlier quoted context omitted.

How much extra money do you think they would make if Claude Code wasn’t JavaScript?

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?

Re: Claude Code uses Bun written in Rust now

#460

Post by benrutter »

daishi55 wrote: post #202
cube00 wrote: post #157

Earlier quoted context omitted.

> Seems to be working just fine though? As with all transpile ports, the true test will be how well it can be extended and maintained over time. Historically working with the output of a transpile is not pleasant and requires heavy rework to get it to the point where you can be comfortable enough to extend it. The existing community is now either going to need to learn Rust or new Rust developers are going to have to…

historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”. This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.

> historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”.

I'm not quite as optimistic. "Unpleasantness" might sound like subjective disgust, but it often relates to objective criteria like complexity, that increases the surface area open to bugs in a real way. Similarly, if reworking has a non-0 chance of bugs, its gonna have some form of risk, and a major one will of course be higher.

LLMs may be capable of a lot, and they miggt change what projects people can take on, but they definitely don't write bug free code.

The bun rewrite/transpile did use some neat ideas like lots of testing and per-file translations, so hopefully they have more in their toolbox than "LLMs hopefully won't be affected by complexity or write bugs"

Post reply on HN