[weakfish]

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.

[switz]

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 rigid API surface contract (and associated tests) will always be easier to trust after a rewrite than a partially tested UI tool with ambiguous functionality.

[coldtea]

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

[weakfish]

Yeah, this is what I’m trying to get at.

There’s two arguments in competition:

1. LLMs make it cheap (in the time sense) and easy to build

2. Rewrites and/or writing something in a native app or program is harder and more time consuming

I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.

I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.

[coldtea]

>2. Rewrites and/or writing something in a native app or program is harder and more time consuming

Why would it be harder and/or more time consuming rather than the opposite? It's like having full specs and a full test-suite to match against the result you want.

[munksbeer]

> I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.

What do you mean? Claude cli is wildly successful. Why do they need to re-write?

[pdimitar]

> I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.

I don't know how you can't see it, to me it's blindingly obvious: risk aversion.

Let's say the risk for a problem is 1%; hell, let's put it at 0.1% even. For a company at this scale even that amount of risk is too much.

I trust Opus/Fable to drive prod database migrations and backfills. I don't trust it with our financial ledger. I trust it with part of the infra. I don't trust it with backups. Etc.

You and others are arguing against a premise that nobody defended, namely "Claude can rewrite everything, for free and with zero mistakes". A bit of a straw man, don't you think?

And that's not even touching the fact that writing a GUI app is difficult for LLMs due to difficulties in it getting feedback and a "feel" whether it delivered what was asked (though I know people are working on it).

> I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.

How does that follow, and from where? I never once noticed any visual jank/lag in the TUI; not in iTerm2, not in Kitty, not in Alacritty, not in WezTerm and not in Ghostty. And even if we exclude those two, me and many other devs are quite fine with a TUI and don't miss a GUI program for everyday coding.

Not saying that our preference is superior -- but it'd be strange to blatantly claim: "for dev purposes, GUI > TUI/CLI".

[weakfish]

Going to give a short reply to one point because I’m about to go to sleep (I try to make an effort to be honest as to why I’m not fully engaging with the entire comment) but re: strawman, I don’t think so. When Dario Amodei is saying SWEs will be replaced soon [0], I think it follows that then he believes Claude can write a native app as well as a native app dev.

0 - https://finance.yahoo.com/news/anthropic-ceo-predicts-ai-mod...

[pdimitar]

CEOs love to promise the sky and the stars. Color me unimpressed.

Now whether they can do it -- that's a separate, and a much more interesting, discussion.

[pdimitar]

> 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 also challenge "fast" -- Fable (and I assume Mythos) are wicked fast and efficient and even they can't compensate for f.ex. slow recompilations or test suite reruns or security scans, linters etc.

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.

[hyperpape]

> $168k

Billions of dollars of annual revenue go through Claude Code, and the people who work on it must be a lot of millions in headcount.

The time matters a fair bit, it's probably time someone can't spend breaking things in the name of new features, but if rewriting the stack had even a tiny impact on retention or driving higher usage, it would pay back that $168k.

[sscaryterry]

If only paying the $168k was some sort of a guarantee. Vibing doesn't give you that.

You might get more maintainable code for $168k by hiring humans, but if its something bespoke it isn't going to get you far (or far quickly).

Vibing is straight out gambling right now, the thing is, I don't know who the house is any more.

[nomel]

It's going to take an order of magnitude longer though, delaying any of that revenue significantly. I'm sorry, but we're talking 11 days here. What does "maintainable" even mean with impossible time-scales like this now!?

[throwaway7783]

.. by hiring the right humans - which is not always a given

[NDizzle]

The company I work for is about 15mm into what is effectively a rewrite. Just a lone data point…

[NuclearPM]

Millimeters?

[pdimitar]

Yep, same thought. And it seems Anthropic agrees.

[mobelkh]

can't imagine rewriting a runtime to be easier than a coding harness

[usef-]

You might be surprised. Runtimes can be easier to test than UI for AI, and the bun rewrite was almost line-for-line translation, whereas CC likely uses many more libraries that cannot be ported directly.

The major open harnesses are in the ~800k lines of code size ( https://simonwillison.net/2026/Jul/15/grok-build/ ) and CC is the oldest and quite-likely largest judging by features.

[pdimitar]

It's really not about a PL runtime vs. an agent harness, it's about how spaghetti and complex the code is. I do get your point though.

[coldtea]

>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 costs, can't be used as an excuse.

[jbvlkt]

Lets see what happens in the future. From my experience cost of maintaining this amount of shitty code explodes pretty quickly. We will see in a few years if SW development in all phases using agents is that much automated and easy as people now predict.

[hluska]

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

[coldtea]

How is that relevant to my response?

The argument I responded to argued that cost might be the prohibiting factor. I'm saying that for them, the costs mentioned are negligible.

[pdimitar]

I don't work for them and I don't know their priorities. I can only speculate they're not okay with it but no idea why exactly.

[TurdF3rguson]

It has to have been purely a marketing move. There's no other way that acquiring a software product for millions and then completely rewriting it makes any sense.

[pdimitar]

Maybe it's one of the cases when techies call the shots?

I can understand people being more sold on Rust compared to Zig -- there are legitimate differences on the memory safety front and I can see how people will prefer one or the other.

Plus I believe Jarred (Bun's main dev) went out of his way to explain why he chose Rust over Zig in his blog post.

Of course the marketing angle might indeed be the explanation; not arguing against that, I simply followed with interest and Jarred seemed very reasonable to me.

[TurdF3rguson]

The rewrite makes sense, it's all their dog food at that point. It's the acquisition that doesn't make sense. Why didn't Anthropic just rewrite it themselves?

[shafyy]

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

Does anybody really believe that it only took 11 days, one engineer and $168k in tokens?

[simonw]

It played out in public on the GitHub repository, so yes.

[pdimitar]

I know what Fable did for just 5x6h sessions, singular agent, for my professional work.

Jarred used many agents and they worked 24/7. It tracks for me.

So yes, I do believe it. What makes you skeptical?

[greenavocado]

100% believe it. I use multi agent orchestration within oh-my-pi and it can absolutely do targeted things like this.

[KronisLV]

> by making it cheap and fast to build whatever you like automatically.

Cheaper, but not free (if you don't buy into the marketing promises too much). The bigger the project, the bigger the cost, even with a discount.

At the same time, the early versions weren't very good and you can be sure that any rewrite will also need to be similarly iterated upon until it is also good enough and polished.

If you do that and don't spend enough effort on making it be something polished --> your competitors have a better product and you lose.

If you pause feature development to give enough effort to the initiative, you don't get to add new features quickly enough --> your competitors have a better product and you lose.

Maybe their priorities lay elsewhere, like how I've noticed that the desktop app version of Claude Code has gotten both faster (no 2-4 second lag when switching conversations), more stable and usable over time, to where I enjoy using the models because of it, not in spite of it (though not that they haven't had bumps along the way, like that one cache invalidation issue, or how people didn't like the auto accept timeout thing). I don't doubt that you can get pretty far with gradual patches and improvements, instead of only big rewrites.

Honestly it's really cool for me to see Kimi having their own CLI too, same with OpenCode, Pi, Hermes (well more of an agent than just a coding harness but you get the idea) - there's so many competing solutions out there, each good or bad in unique ways.

Just wish we'd see similarly many GUI solutions, for now OpenCode GUI seems like the one I've settled on (cross platform and supports most models), though it's not exactly ideal either (feels a bit barebones, especially in regards to sub-tasks and progress/plan tracking, even ZCode seems a bit better in that regard, it was actually surprisingly good after they pushed out some updates).

[arijun]

Can't have been that cheap if they thought buying Bun for an undisclosed amount of money was cheaper.

[tracerbulletx]

I don't think they bought them just for the claude-code gui harness as it is now. it's to have strategic control over some software runtime they can use to do other things related to verification, deployment, and end to end value delivery. Same reason other companies are buying up dev tools.

[arijun]

Yeah it was a little tongue-in-cheek--I think the estimate I saw was over $100M for bun, which would have been enough to pay Donald Knuth to rewrite Claude Code, let alone AI.

[vovavili]

I suspect it's at least partly akin to OpenAI buying uv where they did not want a startup with questionable profitability horizons that serves as a critical piece for their business to get suffocated when VCs come for their money back.

[madeofpalk]

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

[piker]

Right now? Zero.

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

[squidbeak]

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

[coldtea]

Perhaps by then it can be too little, too late, too?

[piker]

Perhaps.

[TurdF3rguson]

Claude is better at Javascript than those other languages though so maybe it would be worse in a better language.

[lacy_tinpot]

>making it cheap and fast to build whatever you like automatically

This can be true, while "nullifies such "business" concerns" can be false. Both are not dependent on each other.

Automation doesn't "nullify business concerns", it just changes them.

[harrisonjackson]

By the same argument, why does it matter from the technology stack side? It doesn't just nullify the business concerns - it largely nullifies the tech stack concerns. Your preference doesn't matter if you aren't touching the code and the product works for your user base.

[jstummbillig]

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

Eventually? I am sure they would agree. Currently it's you (and lots of people like you) who are doing the supposing, not Anthropic.

[tripleee]

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

[benoau]

> They succeeded in spite of their tech choices.

Or those choices just don't matter, it's fundamentally just "tabs vs spaces".

[pdimitar]

As much as an enthusiast dev like myself hates it -- this is innately true, way too often.

I am 46 y/o and still excited to code and solve problems with code and I still have trouble to admit to myself sometimes that people make dozens of millions with PHP and the tech hardly matters when you can throw bodies at the problem (and when that throwing of bodies at the problem actually solves it, of course).

[georgemcbay]

> I still have trouble to admit to myself sometimes that people make dozens of millions with PHP

Or many billions. eg. Facebook was originally written in PHP.

As a 52 y/o who cares deeply about software development as an art I don't have trouble admitting that the tech hardly matters relative to the economics, that was obvious to me very early in my career.

I have just never really cared because there has always been a path where you can have a decent career being paid to work on and with good technology in spite of the fact that the technology wasn't important to the economics.

I do fear that the rapid adoption of LLMs will probably cause the path I took to narrow considerably. There will likely be less companies willing to pay people to work on elegant technology when they are all competing against endless code generation machines (and this is assuming software companies can exist at all in this future). But at my age that's more of a concern for younger people than me.

[pdimitar]

I hear you on the worry, I have the same (and probably so do most devs even).

But IMO the endless churning of code will slow down, if it has not already. Quantity does not equal quality as we know, it even erodes it. There are already consulting companies that are "vibe-code fixers".

I am also not sure it's about "elegant" code. What we might call elegant has multiple measurable axii f.ex. well-isolated effectful code layer so you can easily static-code-check it, domains and enforcement of boundaries between them, bespoke linting to enforce business processes and standing code discipline, and many others.

[groundzeros2015]

Apply this reasoning to any other industry. Yes the average person is not the judge of the quality of a doctor or engineer. That doesn’t invalidate it. You want a doctor who cares about medicine , not whatever will accomplish a business goal.

[azeirah]

Eh, the rendering of Claude Code is genuinely such a mess. I have quit claude code over it because when used as a terminal in PHPStorm it sometimes gets so bad that it becomes hard to use.

This isn't a minor nitpick, it's a pretty major UX issue.

Not saying it's like a massive business downside because I'm just one of a few users, maybe this affects their bottom line a little bit, but probably not by much.

Regardless, switching to pi has been a nice breath of fresh air. It just renders well and smoothly and handles terminal resizes well, which is especially important when used in a terminal window in PHPStorm.

[lucumo]

> when used as a terminal in PHPStorm

Truthfully, the terminal in Jetbrains IDEs just isn't that great. It's gotten a lot better with their rewrites (yes, plural) of the last years, especially on Windows, but it can still be pretty dodgy.

[jamienicol]

That may be so but Claude code certainly has rendering glitches in other terminals too.

[vips7L]

You don’t have to use these “tools”.

[azeirah]

Indeed, and I said I stopped using the tool in the comment I made.

[tripleee]

If they don't matter why isn't GTA6 being built in React?

Tabs vs spaces makes no tradeoffs. Tech choices do

[chippiewill]

The choices were clearly (far) less important than having the best model and a good product that was way ahead of the competition.

However, that's not the same as the technology choices not mattering at all. As others have mentioned the product is buggy, and it appears Anthropic are struggling to continue to release new features within the existing architecture.

That's also not to say that Anthropic made bad choices - there's always going to be a tension between building quickly to capture the market now vs moving slower and building something more maintainable in the long-term.

[troupo]

A TUI outputting nothing but text shouldn't consume 70 GB RAM and yet there they were just half a year ago: https://x.com/jarredsumner/status/2026497606575398987

They couldn't even fix flickering in their TUI and their new renderer is complete garbage.

They succeeded despite their tech.

[enraged_camel]

>> They succeeded in spite of their tech choices.

It is rarely the case that technology choice is the make-or-break when it comes to whether a product is successful and achieves widespread adoption. Some choices are less ideal than others, but at the end of the day if you manage to make something that people want, the rest won't matter much.

[anamexis]

What do you mean in spite of their tech choices? When have the tech choices ever been an issue in the lifespan of Claude Code? From where I sit, it seems like their tech choices enabled them to create an industry-defining product.

[dnautics]

for about half a year claude code had this obnoxious flicker problem. i almost quit and went to codex over it.

[tripleee]

I mean people are using Claude Code because of their underlying LLM - they'll put up with Claude Code. There's no other real option to get Opus at a reasonably affordable price without CC.

Most people would choose to swim a lap through a pool of pee to get a billion dollars at the end. The pool of pee itself wasn't the once in a lifetime opportunity (for most).

Sorry, I'm bad at analogies.

[anamexis]

I may not be the standard case, but I use Claude Code over Codex, OpenCode, Amp, etc primarily because of the UX, not the models or pricing.

[nozzlegear]

> When have the tech choices ever been an issue in the lifespan of Claude Code?

This is just blatantly ignoring all of the glaring issues Claude Code has had over its lifespan.

[solumunus]

I think the point is that people still continued to use it above everything else regardless.

[troupo]

Because there's no legal way to use Claude Code on subscription otherwise

[yojo]

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.

[BoppreH]

> basically anything that isn’t typing characters has had/still has unaddressed bugs.

Oh, that's buggy too. I just tried Claude Code on win10 powershell, and the first typed character goes in the wrong spot and can't be backspaced.

It is by far the the least reliable program on my machine, and every time I have to interact with it I feel like walking in eggshells.

[cvadict]

> I loathe their bug-ridden UI.

So weird that the same exact people telling you that programming careers are now obsolete are the same group who haven't been able to fix screen flickering bugs for like a year...

[yojo]

Oh, and the memory use! I run a lot of concurrent sessions. 3 gigs for a terminal window is ludicrous.

[neutronicus]

The vim mode in that text box was a mess for sure

[galangalalgol]

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.

[bwfan123]

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.

[galangalalgol]

That does seem to be the way many use it. I'd be very surprised if they didn't have to insert a rule to prevent opus from constantly asking why they didn't just use ncurses. I just asked sonnet for design options for a tui to onteract with llms to perform sw dev tasks. After describing the tui it immediately suggested ratatui and crossterm as the tech stack. I feel like they must have ignored even the advice of their own llm to come up with this solution.

Edit, the sonnet question shouldn't be taken as proof, it knows I'm a rust dev.

[simonw]

They decided on the tech stack for Claude Code over a year and a half ago.

[tough]

ratatui was still an excellent choice over a year and a half ago.

Nobody but a JS dev would choose react-on-terminal shenanigans over it

I could see CC getting a ratatui port eventually actually

[jeremyjh]

Bun was not ported to Rust for performance reasons and its not clear to me how anyone can think it was. The reason they've given is memory safety.

[vips7L]

It was ported for vibe reasons.

[galaxyLogic]

Plus 1) There's much more reusable open source code written in Rust than in Zig 2) There are more Rust developers than Zig developers.

[LtWorf]

I don't think there being more rust developers should matter if we're talking about a company that solved coding.

[simonw]

I'm going to guess Anthropic are OK with "fully dependent on AI to fix whatever breaks".

[jubilanti]

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

[zdragnar]

Did it really exist? I remember buying games on discs as a kid that had bugs in them that prevented you from actually finishing the game at all.

I'm pretty sure "built to last" was only ever more true in specific contexts, and wasn't particularly more true than today.

[nozzlegear]

The era in which the [VC-backed, SV area] tech industry built software to last was over long before LLMs.

[weakfish]

Correct

And the question of “if AI is so amazing, shouldn’t it enable easy development of a native TUI even if JS is easier at first?”

Don’t get me wrong I find great value in coding agents daily. Just finding the hype cycle tiring.

[losvedir]

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?

[jolux]

They probably should rewrite it in Rust, but also, I think the Bun guy wanted to rewrite it in Rust because he thinks Rust is a better choice for Bun, independent of Bun being used by Claude Code.

[galaxyLogic]

This speaks for the benefits of JavaScript runtimes like Bun and Node.js. JavaScript is a dynamically typed language which makes it a good choice for explorative programming. It is a Lisp in sheeps' clothing.

Programs which need more stability and performance than exploration are better done in statically typed languages like Rust. Therefore Bun is a platform for JavaScript programming, but itself is written in Zig or Rust.

[tacitusarc]

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.

[realusername]

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

[adastra22]

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

[burner54828182]

> “It largely works”

A ringing endorsement!

[geraneum]

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

[dd8601fn]

...while proving their technology has finally reduced these questions down to what's best, instead of "how much effort will it take to be good enough".

If you have unlimited access to the magical development tool, then why would you not?

But they haven't.

[wonnage]

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.

[solid_fuel]

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

[complianceowll]

I disagree, Solid Fuel.

[solid_fuel]

Nobody cares what a bot account thinks.

[LtWorf]

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?

[overgard]

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.

[DoesntMatter22]

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

[ozozozd]

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.

[groundzeros2015]

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.

[femiagbabiaka]

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

[vips7L]

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

[behnamoh]

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

[reinitctxoffset]

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

[pjmlp]

So Claude isn't great for everything?!?

[ljm]

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 that use curses/ncurses, alongside emacs, vim, almost the entirety of MS-DOS, and so on.

[vmg12]

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.

[wild_egg]

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 2GB of memory to be done poorly with broken scrollback.

[vmg12]

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 highlighting, calculating diffs, and rendering markdown. If the work was split across threads they would not use anywhere close to as much power and there would not be a slow ui.

If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.

The reason the computer gets hot and uses more power is because the cpu is getting close to 100% utilization.

[wild_egg]

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.

[vmg12]

The argument is that doing it all on a single thread will result in high cpu utilization and that is what makes the power usage spike and the pc feel hot. Thats it.

A lot of people go “js is bad” reflexively and they are right for the wrong reasons. Its not because js (specifically v8) is slow. I have many websites and web based apps open and none fuck up my laptop as hard as claude code.

[mixmastamyk]

Stuff doable on a pentium 90, and before that, just slowly.

[hahahaa]

I wonder if those were fast enough nostalgia says yes but I bet it was dog slow if we tried today with 2026 lens.

[cdelsolar]

The heck? It does all that rendering for a tiny fraction of the total amount of time that the TUI is running. The streaming is IO bound, there’s no way that it’s outputting nearly enough text to tax the CPU that much.

[nnmg]

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

[anthk]

Sorry, but nope; Golang there would be there a beast doing that in a much, much faster way. Not to mention C/C++ with NCurses.

[vmg12]

> If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.

Put up the code and prove it. We already know exactly how fast golang is in comparison to nodejs on basic numeric computations, it's roughly 40 to 50% faster.

[skydhash]

That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle.

Bad coding is just bad coding.

[vmg12]

It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.

It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.

[wild_egg]

> If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.

You are really, really not. Not at LLM inference speeds at least. Frontier models output maybe 200 bytes per second on the fast end. I guarantee you that idle BSD box is still processing more than 200 bytes of whatever at any point in time. Streaming 200 bytes of LLM output through syntax highlighting, markdown rendering, and diff formatting, will still leave the box basically idle if done correctly. Claude Code has not done it correctly.

[skydhash]

Processors today are very fast. If you are spiking it on rendering diffs, you’re doing it wrong. I can’t even stress it building openbsd’s kernel.

[zahlman]

> Power usage and heat scale non-linearly with cpu utilization

I don't doubt this, but I would love details and citations here.

[cozzyd]

I'm not concerned with CPU use/wakeups while actively using it, but with it sitting idle doing nothing.

[senderista]

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

[ljm]

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.

[andruby]

This seems a suspicious. How do you measure the CPU load of Ghostty? Is the measure/reporting method just attributing the cpu load of the commands/programs you're running in Ghostty to Ghostty?

You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.

[benrutter]

If you're looking for a non-ghostty recommendation (not that I have anything against ghostty) I use alacritty + zellij and it works fantastic. It doesn't seem to impact battery, I certainly get good battery usage on both my work and home laptops.

[mtlmtlmtlmtl]

I've messed around with pretty much all the fancy new terms to varying extents. Ghostty, wezterm, alacritty, etc. And I'm all in favour of people innovating in this space again. But at the end of the day, I always end up back with xterm. It's reasonably lightweight, runs and is packaged absolutely everywhere, I never have to muck about with termcap files and/or $TERM on remote hosts, and I've never had it break, crash, or exhibit any kind of bug or strange behaviour in over a decade of using it. The only TUI that has some quirks in xterm is Emacs, but Emacs has weird quirks in every term I've tried to run it in, and different quirks in every case somehow, so I just chalk that up to Emacs being weird. I'm sure xterm has some bugs buried in it still, but I bet all of them are in codepaths that are almost never reached nowadays, or at least are extremely niche. It does lack some features like ligature fonts(I just decided not to care), sixels and similar graphics things(again, don't really care) and panes/tabs/yadda yadda(tmux or screen or whatever you like can do all of that anyway).

Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.

[st3fan]

Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.

[agrippanux]

I don't know if its still the case anymore since 1.3 but Ghostty did have a documented issue with Claude causing resource issues.

[tdhz77]

I think the author is saying everything that touches llm.

[LtWorf]

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

[blt]

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

[myaccountonhn]

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

[dmix]

Codex CLI and Grok Build are both in Rust. OpenAI’s web still use react. Previously their CLI was React Ink until they ported most of it to Rust

[jchw]

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's more just "lighter" in general, or it certainly feels that way. It's probably possible to make something with a similar feel in JS, just perhaps not with the big honking mess they've created.

[amluto]

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.

[yoyohello13]

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.

[johnfn]

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?

[weakfish]

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

[jm4]

Probably because it consumes the same APIs originally developed for a web app and the same front end engineers likely created Claude Code. People assume Anthropic set out to create Code as a product and went through a normal design phase. I think it’s more likely it started as an internal tool or someone’s side project and blew up as a product when they released it to the public.

[w4der]

But isn't the point of an API that it abstracts away the language(s) in which your application is written?

[AndrewKemendo]

>Because I’ve been told that Fable can do anything

I hear some version of this anecdote constantly

yet despite using all these prompting tools since 2019 I have never once heard a lab or professional say “x model can do anything”

Can you provide me whatever specific source you heard for this?

[coldtea]

>I have never once heard a lab or professional say “x model can do anything”

Yeah, they "merely" say that they're about to break the singularity in a couple of years, that it's too capable to be safe to release, that it's going to take 50% (or all, depening on the day and audience) of programmers out of work, that it's smarter than Nobel prize winners, that their programmers don't write anything themselves anymore, and things to that effect.

[AndrewKemendo]

Who is “they?”

Again… provide me a quote from someone doing this every day that says: “they're about to break the singularity in a couple of years”

The only people saying this stuff are random Internet commenters, breathless reporters and reactionaries.

The only person on record for a statement like this was Geoff Hinton about radiologists and he has since walked back his statement

[coldtea]

SAM ALTMAN: “We are close to creating a genie that can grant any wish.”

https://x.com/TheChiefNerd/status/2081204789371621744

[weakfish]

It’s hyperbolic and intended to generalize the sentiment I perceive from others.

Dario Amodei said in January that he expected software engineers to be replaced [0], so I suppose the quote should be extended to “can do anything… a software engineer can do”

And I think we can all agree that SWE is on the more complex end of all white collar jobs. So, my thinking is that if SWE can hypothetically be replaced, so can many other jobs. Hence, the claim the models can “do anything” intending to capture the majority of white collar work.

This, of course, is if you take their claim at face value - which I certainly do not.

[0] https://www.entrepreneur.com/business-news/ai-ceo-says-softw...

[AndrewKemendo]

So then nobody actually has ever said that and its explicitly hyperbole

So then its misleading in the extreme to say “I’ve been told AI can do anything”

It amplifies hype when people make claims like this by including hyperbolic statements as though they are reflective of the state of the discussion.

[weakfish]

Alright, sure, my bad. I thought it was clear that it was meant tongue in cheek, but I’ll accept it was unclear.

That said, with respect what I clarified, I’m curious your thoughts.

[Kiro]

Code is the killer app for LLMs so software developers are the easiest to replace.

[weakfish]

Code isn’t what the majority of software engineering is.

[loosescrews]

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.

[jayd16]

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

[ronniebasak]

this. /s

[rafaelmn]

I recently saw a blog post [1] about a famous Haskel shop moving away from Haskell to Python because the iteration speed with LLMs was just that much better. There is so much React in training data, TS compile times are minimal compared to Rust and similar.

I suspect user facing/fast moving code (UX layer) will move to dynamic systems with fast iteration times. Infra layer will move towards safe systems level environments like Rust. I'm not sure where Java/C# lands in all of this - it's kind of the middle ground between these two worlds but the tradeoffs change drastically with LLMs - my gut feeling says that TS/Python is good enough for UX work and Rust is better for systems work so it gets less popular going forward.

[1] https://avi.press/posts/2026-07-10-after-7-years-in-producti...

[kccqzy]

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.

[frollogaston]

Python was faster to iterate on than Haskell even before LLMs

[onlyrealcuzzo]

> If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

It was unpleasantly surprised when I learned the hard way that LLMs are not much better at translating than writing from scratch.

The more you look into how they work, the more you see that it doesn't really give them a huge advantage, if the classes are big enough. You can tell them to break each function up and translate them one-by-one, but the errors compound, you can't test most of it until you have a lot done, and in the end, it really isn't much faster (and sometimes it seems to be a lot slower) then just telling them to start over from scratch.

The downside is... If you have a system that already works, you don't want to start from scratch and test everything all over again...

[miroljub]

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

[lmm]

> why the hell does a TUI need to run in terminal React by way of JavaScript

Because React is the only UI framework that takes the problem seriously. Everything else is stuck in the dark ages.

How HN gets this so badly backwards I'll never understand. Everyone on this site talks a big game about "there shouldn't be so many competing tech stacks, why can't everyone work together on one framework that does things right", and then as soon as that framework actually appears this site hates it more than anything.

[abc42]

>If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.

Yeah, good question. OpenAI decided to rewrite Codex in Rust about a year ago[0].

In fact, since rewrites are that easy, what do we need Bun for? Why doesn't everybody just port all of their Javascript code into Rust?

[0] https://github.com/openai/codex/discussions/1174

[frollogaston]

Code verbosity and complexity still matter with LLM coding

[abc42]

Yeah, they do, but probably not in quite the same way as it matters to humans.

[pianopatrick]

As a counter argument - I assume that Anthropic is using AI to write Claude Code.

I've read and heard in videos that Javascript is a pretty good language for AI to write code in. Apparently this is because there is so much training data out there. Also Javascript avoids problems of multi threading and memory management that can mess up the AI in other "more performant" languages.

So maybe Javascript is not the worst choice for writing software fast with AI

[simonw]

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.

[pianopatrick]

Sometimes I think that if we are willing to burn tokens and rely on compilers in a loop we should be using languages that can catch as many errors as possible at compile time.

Like Ada or Ocaml or Haskell or something.

Or even require like MC / DC testing or MISRA C verification.

Or even some of the languages that apply Hoare checks, like Ada SPARK or FRAMA-C or VALE or whatever.

I don't have the budget to test how that would work but it seems interesting.

[hexasquid]

I presume haskell applications similar to claude code are well represented in the training data.

[pianopatrick]

There was a post recently from a guy who used Haskell with AI agents. If I remember correctly he said the type checking did catch errors. The problem was the compiler was very slow, which slowed down the feedback loop and output. I think he switched to Python.

[vintagedave]

I asked this in a thread with a CC author a few months ago (I felt — and hope — very politely, with similar background.) No reply. https://news.ycombinator.com/item?id=46716974

[simonw]

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

[weakfish]

I don’t doubt his expertise, I just am not convinced it’s the right tool.

To me it comes back to the premise I hear a lot from AI hype men (of which I do not subscribe but it’s worth clarifying that I find great value in using it for code) that the code doesn’t matter anymore. I just don’t know how to square that claim with the idea that we’re limited still by JS/TS being easier to use or approachable despite inferior TUI toolsets.

[hellohello2]

I'm confused as well, could someone who knows how TUIs work explain what's the point of React-style diffing in this context? I thought you need to clean and full redraw if anything changs anyways?

[tredre3]

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

[qudat]

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.

[delusional]

Ncurses is how people used to do it.

[jmspring]

I think Moore's Law and related have made programming sloppy. AI is building on that. There was a time where accounting for memory, footprint, stability, and speed mattered. Your point shows we are well passed that aside from certain areas.

Heck, a buddy and I once chatted about the likelihood of k8s running as the control plane in a prototype autonomous vehicle.

top/btop/htop on the mac are always fun to run and see what's up.

[scrollaway]

Caring for memory mattered more when memory was sparse.

But then again, it's crazy how people are disingenuous. You're in a thread about Bun being rewritten from a non-memory-safe to a memory-safe language and everyone's shitting on it because it's a useless rewrite. How does this mesh with what you say about caring for stability?

Using AI you can actually start caring about things such as memory, footprint, stability and speed because it's crazy cheap to start optimizing for this, when before you couldn't afford to make the tradeoff.

[newswasboring]

Anything that can be written in JavaScript will be written in JavaScript. That's just how it is it seems.

[tokioyoyo]

Cause it works, most users are fine with it, people don't migrate off it because of the codebase, and easier to maintain if the dev team is familiar with code flow.

This is close to the same "why Spotify is a chromium embed?" question. Because it works, and users are ok with it.

[voidhorse]

Probably because claude suggested some kind of wack react based setup early on (because react dominates the training data) and it's be blasphemy worthy of termination for the Anthropic employees to question the sacred pronouncements of the llm.

[bushbaba]

JavaScript is very fast and easy for UI rendering. If it works for web apps it’d also work for the terminal. Sure it’s bloated but it’s fine. The dev velocity of JavaScripts is orders better than rust.

[api]

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.

[sroussey]

So the code for the web, the desktop app, and the cli where largely similar.

[qudat]

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

[cozzyd]

Otherwise an idle TUI wouldn't halve my laptop's battery life. Maybe that's an exaggeration but not that much, based on looking at wakeups in powertop.

[golergka]

I’m not sure what else can you use to share the same business logic between website frontend, desktop gui and tui apps and backend

[frollogaston]

And the TUI fights the terminal on basic things like copy/paste. I end up telling Claude to write all outputs to a tmp file.

[groundzeros2015]

The answer is those are the tools their lead engineers knew, so they repurposed them rather than learning other paradigms .

[antonvs]

To the man with a hammer…

[mexicocitinluez]

This saying has been abused 10 ways til Sunday.

"I'm using technology I know that will get us there" is not the same as treating every problem as a nail. It's making a practical choice that probably also had time constraints and other factors we don't know.

[antonvs]

> "I'm using technology I know that will get us there" is not the same as treating every problem as a nail.

Hammering in a screw is using technology that the hammer-wielder knows will get there. You’ve just rephrased the statement.

What you seem to be saying is that in some cases, the hammer may be the appropriate tool. No-one disputes that.

[mexicocitinluez]

How do you know it wasn't the appropriate technology?

My point is that the idiom has now come to mean "I disagree with your tech choices".

[groundzeros2015]

I think it’s completely applicable here. Nobody who worked in the 80s or 90s would have selected this solution.

[mexicocitinluez]

> Nobody who worked in the 80s or 90s would have selected this solution

How does this support your argument? The tech didn't even exist in the 80s or 90s.

Saying "They wouldn't have made the same choices 40 years" is meaningless in this context. There's a lot of things they wouldn't have done back then that we do today. And this is a field that has been changing by the week recently, which makes even less appropriate.

This idiom now apparently means "I disagree with your tech choices" or in your case, "Someone 40 years ago would disagree with your tech choices".

[groundzeros2015]

Let me clear up your confusion.

I did not say they wouldn’t used react in the 90s (obviously). Anybody familiar with terminal uis (a technology which did exist) and perhaps any other ui system would not have chosen this design.

And no it’s not just me as evidenced by the many confused comments any time this is brought up.

[onetrickwolf]

> why not rewrite CC in a native language?

It's hell to maintain for not much gain (for a use case like this at least). As much as it's become a meme, JS and web tech in general has become extremely portable and stable.

I also don't think Anthropic bought bun to make their TUI better. They could have forked it, they bought bun because it incidentally was excellent for the way agents prefer to work and they wanted to capture that audience.

[vips7L]

I thought maintenance was free with LLMs???

[tayo42]

I don't think it's that kind of maintenance like code.you need to test cross compiling and running on different platforms. I guess js acts like how the jvm is

[simonw]

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.

[geodel]

> 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 this does not get Anthropic 'The Presidential Medal of Strategic Restraint' I don't know what will.

[keeganpoppen]

it is kinda mystifying bc from what i understand their engineering ethos is very much "if it's not working, just regenerate it" (which i completely understand).

[deadbabe]

Should have done it in C++ with SDL3.

[mischief6]

i got annoyed by this especially the memory use and non portability aspect of bun so I had claude (lol) and kiro cook up my own agent. it runs on linux, openbsd and even on omnios and esp32. it's just a personal project so there are probably rough edges, but I am using it on my clockworkpi uconsole daily now. https://github.com/mischief/clm

[ozgrakkurt]

If you think that way I would recommend just keeping away from these topics. It is just useless arguing and speculating about things don’t matter.

I have been trying to keep away in the last couple weeks and it was all win for me. I still come down here sometimes when I am stressed with real work since it is a strong addiction to see “how terrible the plebs are doing”.

[fny]

JavaScript is dynamic and supports live reload which means iterations are far faster than would be in a compiled language--even for LLMs.

This is especially useful when you're trying to evaluate behaviors while changing state surgically.

[amoss]

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.

[pjmlp]

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

[nozzlegear]

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