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 would rewriting Claude code, an app which probably has 30-40 (I might be significantly underestimating) extremely active contributors be easier than rewriting Bun, which has fewer contributors and almost certainly also less lines of code?
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…
Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?
Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since.
This does not even speak to it pegging my CPU and keeping the fans running on full blast even when the laptop is supposed to be idle overnight.
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
There were very many open pull requests from the community that were all invalidated overnight for something that same community was assured was merely an experiment. The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed har…
None of that is needed. Nobody benefits from all that time wasting bureaucracy/corpo speak. Bun is quick to deliver new features and bug fixes. With this change, the hope is that'll only get faster.
All those PRs can be fed thru Claude and converted to rust and then manual polish can be added.
Why does changing to Rust kill the project? I don't understand the point here.
> Why does changing to Rust kill the project? I don't understand the point here. I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors. Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way…
A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. That somehow kills the project. ok!
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…
The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.
So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for software that is intended to be built to last, I dont see this approach working out.
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…
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!"
The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.
So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for softwar…
> for sw that is intended to be built to last, I dont see this working out.
the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.
Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated. Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
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?
What's the point of rewriting it to Rust if you're going to, on purpose, disable the most prominent benefits of using Rust?
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…