>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 whatever you like automatically.

That they wont, or worse, couldn't, speaks against that.

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

I have been working all day every day in Claude. I loathe their bug-ridden UI. Every release is a new crop of bugs, sometimes the old ones get fixed, usually not.

Any kind of scrolling back, copying text, using their menu system - basically anything that isn’t typing characters has had/still has unaddressed bugs.

OpenAI shipped a competitive model and I’m over in Codex now. I have yet to hit a bug.

If you’re holding the SOTA crown, people will put up with your buggy mess. As soon as that crown slips your pile of trash becomes a huge liability.

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.

This reply makes no sense in this context, though. Sure, it exploded in popularity based on whatever random tech choices were made. But now, when apparently they're deciding there's a problem there, why unleash $150k of tokens to rewrite a JS runtime wrapper from Zig to a million lines of rust, rather than simply rewrite Claude Code itself to rust?

This is the “eating yogurt with a hammer” argument. Yes, of course you can do that. Yes, the yogurt gets eaten. It’s just… you see someone eating yogurt with a hammer and it’s hard not to wonder wtf is going on.

Massive business success? I don't know the financials since they're not published, but google says the acquisition cost low hundreds of millions. So they could throw away the code and rewrite it.

Claude code still can’t handle scrolling history without corruption. It is embarrassingly broken.

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

The engineer is suggesting that it could be done cheaper and maybe with better outcome. Ironically, this is a classic business case.

> “It largely works”

A ringing endorsement!

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

This is a confusing comment because it’s the exact argument you would present against rewriting Bun to Zig, but you are arguing for one and against the other.

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.

Any choice would have made obscene money in this market. It doesn’t make it a good choice.

It doesn’t work, it performs horribly and is full of bugs. Serious people use open harnesses.

For a company that solved coding and doesn't need any software engineers… why spend money to acquire a runtime rather than ask claude to rewrite it in assembly directly and be done with it?

Could it be that they aren't being entirely honest?

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

I'd argue these tech companies got popular because they have good models, nothing else.

Even OpenAI took two years to fix basic chat scrolling.

This is far less so in this case because this is thier hot path. Everything runs through it and tens of billions in revenue depends on it. It needs to be as fast and solid as possible

This is a useless post-hoc rationalization. "It worked out, so it doesn't matter". You're trying to galaxy brain yourself into ignoring the obvious conclusion.

The point is that if you were starting a new TUI LLM harness today, you would basically use CC's architectural decisions as a guide for what not to do.

So Claude isn't great for everything?!?

No, it's because they wanted a unified pipeline in claude code, claude app, and their website. All of them use more or less the same claude features (claude code has artifacts, claude website has "Ask User a Question" tool, etc.).

Much less fragmented compared to "write the app 3 times in 3 different languages".

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

[dead]

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 Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu.

Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto.

But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.

Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?

> Even when the laptop is asleep overnight it's practically melting.

Then something is waking it up and it's not asleep at all. Asleep the CPU shouldn't be running.

yep, developers from 10 or even 5 years ago would have considered it a hilarious joke

Its so wasteful, but that tracks with the modus operandi of AI companies.

That blog post doesn’t make sense to me at all. The author is going from full modern Haskell (since he mentioned Servant and Beam, you could tell almost every file uses dozens of GHC extensions beyond what Haskell2010 gives you) to Python with dynamic types. He could instead rewrite the Haskell to use less modern type system features and get so much faster compilation speed.

Also GHC has an interpreter. It powers the REPL. No need to compile everything if you’re just experimenting. I do find that in the Haskell world the REPL is criminally underused compared to Python.

And the rest of your comment doesn’t make sense; this shop is rewriting their infra (not UI) from Haskell to Python.

Python was faster to iterate on than Haskell even before LLMs

Because I’ve been told that Fable can do anything :-)

My question is moreso “why was it ever JS in the first place”

& the cost of a native rewrite would be cheaper than acquiring Bun no matter how you shake it

I'm doubtful that it has fewer lines of code, but even so, it is almost certainly less tricky and simpler code. You could also rewrite it in a higher level and more forgiving language than Rust (e.g. Go) and get huge improvements. The improvements would probably be much bigger than the improvements they have achieved at the JavaScript runtime level.

I don't think people are saying it's easier, they're saying the results would be better.

this. /s

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.

Code verbosity and complexity still matter with LLM coding

I feel like a year ago JavaScript and Python were the best languages for coding agents to use because of their heavier presence in the training data, but I'm not sure that's true any more now.

The latest frontier models are competent at Rust and Swift and all manner of other less widely used languages.

The more important factor is how good they language's compiler is at kicking out actionable error messages, since one-shot code generation isn't as important once you have a coding agent loop.

At a guess it's because Boris literally wrote a book on TypeScript: https://www.oreilly.com/library/view/programming-typescript/...

> I thought you need to clean and full redraw if anything changs anyways?

Unless you use an ancient teletype, you don't have to redraw everything. That would make any interactive applications way too slow/flickery.

You can move the cursor arbitrarily in the terminal and start overwriting characters from there. So you need to track state to know what is "dirty" and needs refreshing. Occasionally you issue a full redraw to catch missed artifacts left behind or when the terminal is resized (SIGWINCH).

You can do damage tracking for TUIs. Printing to the terminal is done by moving the cursor and redrawing the line the cursor is on.

Ncurses is how people used to do it.

The component trees have to be rewritten, only the non-view related JS code can be reused.

To the man with a hammer…

I thought maintenance was free with LLMs???

I think they bought Bun because it was a supply chain risk for them.

Their new flagship product (earning them billions of dollars in revenue per month) was dependent on a platform maintained by a tiny startup.

Buying Bun was a very rational way to reduce that risk, epically since it also got them some top tier engineering talent.

Thinking about that further, I wonder if that was part of the rationale for switching from Zig to Rust that they haven't talked about?

Zig is a much riskier bet for your multi-billion dollar cash cow than Rust is.

But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.

If you are relying on live updates to change state in a dynamic language then you are not doing it "surgically", unless there is some other definition that means hitting it softly with a large rock.

There are several compiled languages with live reloading, including C++.

There's no surgery when you're a company with a trillion dollar hammer and every problem looks like a big ass nail.