I very much doubt they would want to abandon the wider community. They do benefit from others using it.

To the contrary, I think any problem with this release would be jumped on harshly so they're being more careful than usual. There's not a rush for the community to move to 1.4 and any issues could poison the community trust.

Like this rewrite did not terminally poison trust?

Has it impacted your use case negatively?

Anyone know why? Can’t CC run on any JS runtime?

Yes, but it’s slower on non-bun runtimes. Nowadays, I believe they bundle bun with CC

They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.

AFAIK, they have written a new renderer.

> They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.

That's such a stupid engineering choice that it really makes one question if the people working at Anthropic have any software engineering ability at all. There's no excuse for running React in a freaking TUI.

>AFAIK, they have written a new renderer.

Which is equally terrible and has earned them every single rendering engineer in the world taking the piss out of them when they proudly announced it was as complicated as rendering a video game.

> They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.

The source of the performance issue here is their own incompetence, actually. I have never in my entire career heard of a rendering pipeline as idiotic as the custom one they built.

because their js code is so bad and slow that they need the bun performance hacks and optimisations.

Do these hacks make bun less secure than other runtimes? I find it a little hard to believe you can get much more robust and performant than V8 or SpiderMonkey without cutting some corners that notably went uncut by either for all these years.

Bun uses JavaScriptCore, which is Safari’s JS engine, for the actual interpreter portion of its runtime.

Which makes the parent comment’s “Bun performance hacks and optimizations” sound a little far-fetched, at least in this scenario I don’t think that’s gonna be the deciding factor. Their vendored JSC is also not touched by this port-rewrite at all whatsoever (still Cpp), so I’m not sure if it’s even possible to hack-improve all that much there.

yes, especially compared to deno bun does not have proper isolation or permissions at runtime layer which is why anthropic tries to fix the lack by a mixture of app layer (build into claude code) and os layer (srt) however using runtime permissions would allow much better security if done right.

It's just a marketing stunt. They've got the ad for Claude-powered code rewrites, and that worked beautifully. Everyone got the message: spend big bucks with Anthropic to get rid of whatever codebase bugs you - please, think of the IPO!

If it was about Claude Code itself, they could have rewritten it. They keep saying they don't even write code any more, so it shouldn't even matter what language it's in.

If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust? That likely would be far more efficient than changing the language of your typescript runtime that ships to run your react-based CLI app.

I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.

If you look at the reasons for rewriting Bun [0], they weren’t about efficiency and they don’t apply to Claude Code. It’s already written in a memory-safe language, and doesn’t have to interface to a library with a tricky set of invariants.

[0] https://bun.com/blog/bun-in-rust

> If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust

Rewriting a runtime with well-defined interfaces and behavior is quite different from rewriting a user-facing application under active development by a decent chunk of their organization.

I agree, but this difference is very frustratingly omitted from the hype-sphere surrounding the rewrite, even though most software developers don't work on a runtime with well-defined interfaces and behavior. I know a number of people who've developed severe FOMO that their projects take longer than 2 weeks and maybe it's because they're not AI native enough.

(I don't mean to be critical of the Bun maintainers, who have always been open about the fact that they leveraged the specific context of their project to do this effectively.)

Why wouldn't they?

Bun is a major part of the web ecosystem, having it developed by them via AI, sounds like a gigantic pr win.

It’s not. Node is part of the web ecosystem. Bun was a way to upsell paas

> Bun is a major part of the web ecosystem

It was never that large but it did have a shot at getting more popular - until this drama.

No one worth their salt is building on Bun anymore, the creators and maintainers of bun have demonstrated their complete lack of care around engineering and support. It’s just too risky.

I regularly use bun, it's a decisive speed improvement over node. Large parts of the ecosystem build on bun.

If you install bun you're still getting the zig version.

I don't see major reasons to doubt the rust rework, especially as so much capital and token investment is being thrown at it.

As long as it fits better than alternatives, I see no major reasons to change.

> If you install bun you're still getting the zig version.

> I don't see major reasons to doubt the rust rework, especially as so much capital and token investment is being thrown at it.

You shouldn't trust the rust rework. Despite the mountains of capital and token investment which have been thrown at it, they still only ship the zig version to users.