Claude Code uses Bun written in Rust now

https://simonwillison.net/2026/Jul/19/claude-code-in-bun-in-rust/

by tosh • 4 days ago

606 822 4 days ago

For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.

And so, the FOSS project "Bun" silently dies in darkness and is now something completely else. I'm glad I still had "Investigate if Bun is worth it" on my TODO list and hadn't yet gotten to it.

What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?

minraws• 4 days ago

It's largely just what jarred is willing to accept this week afaik or not, and they did put the bun 1.4.0 version bump in the changelogs for claude code a while ago, over a month almost.

Though most will be forgiven to not reading it since well it's all AI anyways. I don't know how I feel about all this yet, maybe someday.. ooof

jdiff10• 3 days ago

they did put the bun 1.4.0 version bump in the changelogs for claude code a while ago, over a month almost.

Where? Is see no CHANGELOG in the root. I do see LATEST, last modified 2 months ago, and it says 1.3.14

junon• 4 days ago

Why does changing to Rust kill the project? I don't understand the point here.

Cthulhu_• 4 days ago

Yeah same, according to one of the Zig team members, the original source code wasn't all that anyway.

But this is HN, a subsection of which places a high importance on what language something is written in, moreso than what it does (feels like).

_pdp_• 4 days ago

I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.

embedding-shape9• 3 days ago

I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.

afavour8• 3 days ago

The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. We don’t know what’s actually in it.

foxes• 3 days ago

As an open source - community driven project? Have you looked at the repo on github?

Theres thousands of PRs from claude agents or whatever.

Yeah really feels like a worthwhile place to contribute lol.

atonse7• 3 days ago

It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.

I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake.

I’ve never met Jared or the bun team but I don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in?

It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.

locknitpicker2• 3 days ago

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 out of their way to push implementations that consume the complete rewrite before the world has access to it.

I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.

OJFord2• 3 days ago

Emphasis on the FOSS project. The v1.4 mentioned is not (yet?) open source, Claude Code is essentially using a proprietary fork, was GP's point.

pjmlp8• 3 days ago

Definitely, it was a possible reason why Zig actually matters in the industry.

Now it is a Deno clone, both without anything enticing over node.js.

jeroenhd• 3 days ago

My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim.

I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me.

Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.

stymaar• 3 days ago

Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared.

“bun the JavaScript runtime ” is not dead though.

hoppp• 3 days ago

Bun is now mainly the runtime for claude code. All changes will go in to make claude code better.

It's not about making the dev experience better than node, that use-case is now secondary.

amazingman• 3 days ago

I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic.

ranguna• 3 days ago

The PR is public, you can build and use it as well. The anthropic team just decided to use it, and you can as well.

embedding-shape9• 3 days ago

The PR is public

I'm talking about the 1.4.0 release:

Claude supports them shipping a preview of a not-yet-released Bun version

Maybe Bun/Anthropic fixed this after Simon's initial release of the blog post, but seemingly when we both looked, it wasn't public.

TheRoque• 3 days ago

I had "investigate if bun is worth it" too, and decided not to use it, but instability was one of the reasons. So it feels it was the right move.

baq2• 4 days ago

Turns out it was just a build step after all.

kburman• 4 days ago

Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong.

If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development.

Today's AI-generated rewrites may not produce code that humans would consider high quality or maintainable. But I'm beginning to wonder whether that will even matter in a few months. If AI is the primary consumer, maintainer, and refactorer of code, human readability becomes far less important than correctness, performance, and the ability to iterate.

This feels like a shift where software may no longer exist as a long-lived artifact in its current form. Instead of writing and maintaining applications for years, we may generate, adapt, and discard them continuously for each use case.

sdevonoes• 3 days ago

We are the ones to get to decide. Do we want that? I don’t. But im just a single data point

rho1383• 3 days ago

That sounds like a massive waste of finite energy and compute resources.

CrimsonRain14• 3 days ago

That's like saying let's stay with horses.

We'll develop faster and better tech. We'll find resources to feed that. Use that to build better. Access better resources. We'll mine asteroids. We'll harness much more from the sun. The factory must grow.

esjeon• 3 days ago

But I'm beginning to wonder whether that will even matter in a few months.

At that point, even Bun itself doesn't matter. All intermediate tools don't matter if LLMs can reliably write something large.

The problem is that LLM is not quite there yet. The rewrite was only possible because they mostly stick to 1-to-1 translation resulting in non-idiomatic Rust code. So, what from there? I don't think they can really build up a sane codebase from that state. They only shot themselves with a bigger gun.

brabel3• 3 days ago

The rewrite was only possible because they mostly stick to 1-to-1 translation resulting in non-idiomatic Rust code.

That’s patently false, just read Jarred’s own blog post describing how that was the first stage only, they went through many more to get the amount of non idiomatic, unsafe Rust code to an acceptable level.

jqbd4• 3 days ago

Isn't it just: "while true {refactorIdiomatically(); fixErrors()}"

whateveracct• 3 days ago

Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong.
If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development.

exactly. this wasn't a technical project. this was a marketing stunt that worked on you.

fg1372• 2 days ago

I initially thought rewriting an entire codebase with AI would be a huge mistake

Keep in mind that you are not Anthropic, and you'll likely NOT consider rewrite at all if you don't have unlimited budget

davewritescode• 2 days ago

Some of what you’re saying is likely true but quality is something that will never be optional. There is quantitative data suggest that LLMs perform better on higher quality code base which makes sense. Code that is well organized and coherent will make better use of the context window.

Software refactoring and tech debt is absolutely where LLMs will shine as is evidenced by the Bun rewrite.

gabrieledarrigo• 3 days ago

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

The communication is the issue, and it was handled very badly, in a way that impacted trust and divisions.

Was it so difficult to adopt the approach that the TS team adopted for 7.0?

baq2• 3 days ago

I guess the point is none of it matters, CC users didn't notice or don't care except an exceptionally small minority.

snemvalts• 3 days ago

The lowest of the bars

conartist66• 3 days ago

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"

zarzavat3• 3 days ago

Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.

raincole2• 3 days ago

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

cush3• 3 days ago

There's literally nothing stopping anyone from continuing the Zig version if they want to

pier253• 2 days ago

You mean except the bugs in the zig version and any future CVEs?

ozozozd3• 3 days ago

Serious adults?

They are in extremely short supply right now.

It’s a mix of serious-wanna be, quasi religious, quasi-technical people running the show right now.

I am so happy to I got to read about the 90s-2000s tech culture, and experienced the post-2008 startup culture.

Just about 10 years ago people were really serious, but chill-looking. Somehow that got flipped.

polynomial• 3 days ago

The wig-vs-grok periodic cycle.

kzrdude• 3 days ago

Mario Zechner's talk "Building Pi in a World of Slop" is a good listen, on the topic of adults in a "world of slop". https://www.youtube.com/watch?v=RjfbvDXpFls

randysalami3• 2 days ago

Sometimes being unserious is actually very serious. See current US administration.

mlsu• 3 days ago

It really does seem like they should have been able to do an incremental rewrite with FFI. Could have easily done it with AI too.

classicposter• 3 days ago

Yes, they probably don't know C ABI.

NewsaHackO5• 3 days ago

I don't know, I feel as though Bun went about it much more maturely than zig at any point in the process, from the initial attempted zig compiler commit by the Bun team to the Zig dev team member response to the Bun Rust blog post. Also, I think that fallout over this whole event will definitely favor Bun versus Zig.

raincole2• 3 days ago

It's a weird way to frame the event. Yeah, Andrew (Zig)'s responses were astonishingly immature, but it doesn't matter. Even if Andrew literally ate baby seals for breakfast and kicked puppies as a hobby, it wouldn't make Bun look better. You'd notice that the parent comment didn't even mention zig at all.

pier253• 2 days ago

This is the exact reason I stopped using Bun for new projects.

Terrible project governance.

TS 7 is a good example of what a responsible team that cares about their users should have done.

randysalami3• 2 days ago

There was a recent post on here with a Claude Code issue I and others responses to. Specifically, the person from Anthropic who caused the issue replied on HackerNews. In it, he claimed he was the sole contributor and reviewer of the code into production, that he would “do better” in the future. Commenters were confused how a company like Anthropic could allow something like this occur and for an engineer to publicly admit a complete failure and negligence of build processes.

It’s clear seeing your post here a couple days later what’s going on. It’s deliberate. I can only speculate on their reasons why but it seems to be an intentional form of disrespect on the engineering culture. “Your norms, your work, your principles” mean nothing. We can spend money and invalidate your life’s work. We don’t need your consent or support. That’s my personal guess at a surface level.

bel8• 3 days ago

Contrary to many, I have high hopes that Jarred and team will lapidate the ported codebase and it will continue to flourish as an open source project.

znpy• 3 days ago

Startup got 10% faster on Linux but otherwise, barely anyone noticed.

Just that?

I was expecting more from that rewrite. Maybe Rust is not so worth it after all.

IshKebab3• 3 days ago

I don't think their motivation was primarily user-visible stuff. They backed themselves into a corner by forking Zig, and also were fed up with fixing memory errors.

You wouldn't notice either of those if you were a user, unless you happened to hit one of those bugs.

ifwinterco• 3 days ago

It was already written in a very performant language so no significant performance improvements should be expected.

The benefit of a rust rewrite is memory safety improvements, but currently they've just rewritten zig to unsafe rust so they don't have that either yet

voiper1• 3 days ago

The blog claims rust chosen mainly to address memory issues, which rust is a better language for. So, success would simply be less new memory errors / easier to patch old ones.

marcindulak• 3 days ago

Claude installer/updater had a high memory usage problem (Gigabytes of resident memory used during a fresh installation of Clade with it's native install.sh script, or during a claude update). This was reported as early as December 2025, see https://github.com/anthropics/claude-code/issues/12327#issue....

The latest Claude installer (2.1.215) possibly does not have it anymore https://github.com/anthropics/claude-code/issues/4953#issuec..., but more tries on various machines are needed to confirm that.

ooofydoofy• 3 days ago

bun upgrade --canary

you are welcome

reddalo• 3 days ago

Damn, I should have not migrated to Bun. Should I revert back to Npm?

cromka3• 3 days ago

I am getting into the frontend dev and one thing that I don't understand is why people use bun in the first place? It's not much better preforming, it's not much safer, it's still not 100% compliant. Some tests show it's actually slower than node. Why bother switching, then?

johnny22• 3 days ago

i assume it's because of all the built in tooling that node doesn't ship with.

awestroke• 3 days ago

Faster package manager

Faster startup

Typescript support out of the box

Better stdlib than node

Stdlib includes yaml, sqlite etc so you need to pull in fewer deps, so you can avoid the left-pad/is-even node_modules explosion problem to a greater extent

vips7L7• 3 days ago

I don’t think you would use Bun for front end.

frollogaston5• 3 days ago

So much of JS dev is just saying no to random new stuff, Bun included

vaughnegut• 3 days ago

There's always deno

jqbd4• 3 days ago

but it's written in Rust too /s

orf• 3 days ago

What specific technical issues are you experiencing with running Bun that would justify a change?

IshKebab3• 3 days ago

This post is just "they didn't lie"...

thrance• 3 days ago

Yeah, I noticed. I had Claude write a quick JS script for me a few days ago, it then tried to use Bun to run it. When it couldn't find it, it tried to install it with `sudo pacman`. I had to fucking tell it to use Node instead.

maverickaayush• 3 days ago

I've been using Claude Code daily for a fairly large FastAPI project and didn't notice anything unusual around that timeframe. If this really was the Rust runtime underneath, "boring is good" seems like the right outcome.

rs_rs_rs_rs_rs• 3 days ago

It is absolutely amazing to me that this ai rewrite work so well, maybe claude is not really that much of a complicated tool to stress the bun runtime but still...

jqbd4• 3 days ago

It works well because they had tests, they could compare before and after. Likelihood of issues especially if you transpile to a safer language should be minimal.

feverzsj2• 3 days ago

It's a transpile. And not even a good one. The generated code is far from idiomatic rust. Some may consider it an abomination.

alexandra_au• 3 days ago

grep -nr 'unsafe' .

Is all you need to know to consider how much of an abomination it is

simonw22• 3 days ago

This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10:

  2026-05-14 23427db 13907
  2026-05-14 19d8ade 13861
  2026-05-15 4d443e5 13840
  2026-05-17 172afa5 13803
  2026-05-17 80a06a8 13849
  2026-05-18 fba43af 14026
  2026-05-19 303cd28 14052
  2026-05-20 21db682 14243
  2026-05-22 a06a00a 14239
  2026-05-23 49c97de 14090
  2026-05-28 472a06a 14076
  2026-06-01 a0d1472 14071
  2026-06-04 8553428 14032
  2026-06-09 717542f 14053
  2026-06-10 1c90e5a 14043
  2026-06-11 6e91d24 14031
  2026-06-16 bd8edc7 14086
  2026-06-17 6ef5977 14104
  2026-06-20 315ed50 14106
  2026-06-22 c6be834 14120
  2026-06-23 ea7e44f 14108
  2026-06-23 03042ab 14128
  2026-06-29 86d32c8 14046
  2026-07-01 6640fcf 14077
  2026-07-04 51074e3 14099
  2026-07-06 9d0e93d 14186
  2026-07-08 ab6eb2d 13953
  2026-07-09 86caf6e 13936
  2026-07-10 91675d0 13930
  2026-07-13 73b6c14 13951
  2026-07-16 4bbe075 13978
  2026-07-16 57e30a5 13995

So not as much cleanup as I had expected!

ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...

rwz2• 3 days ago

The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had.

Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence.

All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?

brabel3• 3 days ago

Can you show some examples of abominable Rust code they have?

amelius• 3 days ago

Why not transpile directly into LLVM IR?

jqbd4• 3 days ago

I don't think AI or humans are trained well on it.

daishi554• 3 days ago

Seems to be working just fine though?

And like, this is just the beginning of the port. They did a mechanical port basically line by line, next step is to make it idiomatic rust.

I thought by now people would’ve learned to stop betting against this rewrite.

cube004• 3 days ago

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 join the project and they may not invested enough to refactor the transpiled output when they could work on something else like Boa.

endospore14• 3 days ago

next step is to make it idiomatic rust

You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.

brown9-2• 3 days ago

Is it important to be idiomatic if the project meets its goals around memory safety?

feverzsj2• 3 days ago

If it's not idiomatic, the memory safety won't be guaranteed.

kikimora• 3 days ago

No, but the project does not meet its goals around memory safety. It is usage Rust all the way down with same memory safety issues.

variadix• 3 days ago

Yeah I don’t understand this port at all other than as a big marketing stunt.

It would have made far more sense, for reliability, efficiency, cost, etc., every metric really, to use or write a source to source translator that preserves as much structure from the original code as possible. Typically if you do a rewrite there are lessons learned from the existing code base that you want to take into account when doing the rewrite; using a bunch of agents to do the porting file-by-file buys you none of that. In either case the code will be an unidiomatic translation, just with LLMs you get an added source of indeterminism and a huge bill at the end of the month.

luckydata• 3 days ago

given enough time and tokens, it will become that. I really don't understand how that is a problem in any way.

vips7L7• 3 days ago

LLM code has always been an abomination.

aureate2• 3 days ago

The port of Bun, which has >5000 open github issues, is used in Claude Code, which has >11000 open github issues. Do people use Bun in things that are expected to work reliably? Have any such projects tried the upgrade yet?

ivanjermakov• 3 days ago

11k in two years vs 5k in two weeks? You're right, numbers speak for themself.

entrope2• 3 days ago

Did Bun mass-close issues that predated the rewrite? It doesn't look like they did, as the oldest open issue is from 2021 and there are many from 2022, but maybe they did something that killed most of the old issues.

zahlman2• 3 days ago

To be fair, https://github.com/python/cpython has over 5k open github issues, and that's still generally considered fairly reliably technology even if a lot of HN users seem to hate it.

aureate2• 2 days ago

It's not a great way of inferring software quality, but I think the numbers for both Bun and Claude Code are pretty bad.

cpython has ~7,000 open issues, but ~70,000 closed ones, a 1:10 ratio. Bun's ratio is above 1:2.5, while for Claude Code it's slightly over 1:6.

Much more importantly, though, Bun's oldest issue is from Sep 2021, while Claude Code's is Feb 2025. cpython's oldest issue dates from June 2000 (presumably migrated from an older tracker). Claude Code has very nearly the same total number of issues (open + closed) as cpython at around 77,000, but Claude Code has done it in a year an a half whereas cpython has taken 26 years to get there.

It's a good comparison to pick, as it can't be explained by popularity. For all the real-world use Claude Code sees, it's nowhere near what cpython sees, even over the year and a half in question. Bun, meanwhile, is hitting these numbers while not even being the mainstream choice for what it does (node still holds that crown afaik).

witx• 3 days ago

What is the actual contribution and motivation of this post?

simonw22• 3 days ago

I thought it was interesting. I didn't write this with Hacker News in mind.

(I was actually half way through writing about something related, when I thought it would be interesting to see if I could prove that I had the Rust version of Bun on my laptop already.)

owebmaster• 3 days ago

[flagged]

tomhow• 2 days ago

Please don't attack people on HN, even with vague insinuations. The guidelines ask:

Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.

https://news.ycombinator.com/newsguidelines.html

softwaredoug3• 3 days ago

People shouldn’t overthink blog posts. Just write what’s on your mind and have fun.

rvz2• 3 days ago

The motivation is obviously clear. No-one would be doing that for fun 24/7, only covering about AI and nothing else without getting paid for it.

If anyone else did that on HN, they would be accused of slop with their domain blacklisted.

sensanaty2• 3 days ago

[flagged]

simonw22• 3 days ago

I've not made any money at all from Anthropic.

You can see my list of previous weekly blog sponsors here: https://simonwillison.net/dashboard/sponsor-history/

None of them get any influence on my content. That would hurt my credibility, and my credibility is the reason my site is worth sponsoring in the first place.

Honestly, if OpenAI or Anthropic offered to sponsor I'd probably turn them down. The optics of taking sponsorship from companies that I frequently write about are not great.

codethief• 3 days ago

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.

PsylentKnight• 3 days ago

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

LambdaComplex• 3 days ago

Does exiting following by resuming the session fix it?

anematode2• 3 days ago

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

kilroy123• 3 days ago

I'm far from being anti-AI, but these guys take it way too far IMO. It's straight-up AI slop. Like a real engineer still needs to be in the loop and drive the tool.

Anthropic seems to be all in on 100% AI code.

NateEag• 3 days ago

I've been (grudgingly) using Claude since February.

When I started, I discovered to my shock that it was by far the worst TUI I had ever touched. Rendering glitches, keyboard input screwups, and just all-around jankiness.

Despite that awful baseline, I have to agree that it's gotten noticably worse in the past week or so.

It's started mangling my terminal sessions somehow, so that not all characters I input are visible in the UI.

Backgrounding it, doing a 'reset', then re-foregrounding seems to fix it.

Of course when I asked it to diagnose the problem, it assured me that Claude has no such big and it must be something else I'm running.

All I'm running is tmux and Claude, though, and the behavior surfaced while I was running Claude.

So, yeah - if they just recently updated Claude to use the Rust rewrite, this increased crappiness might actually be due to that. It does seem to at least roughly correlate.

tappaseater• 3 days ago

Anthropic bought Bun, so they kinda, sorta had to make this work. I am sure the cost at $145,000 in Claude time will get some attention.

I am curious how this will work going forward from FOSS perspective. Will humans be allowed to modify the generated code? Only the .md prompts for the agents? Or what?

nottorp• 3 days ago

So does that make Claude Code any better?

Can you select text with shift + arrow keys now in the command line client? :)

softwaredoug3• 3 days ago

Whatever the headaches of the internals, I haven’t heard any substantive outcomes in hacker news that have been impacted by this change.

Yes if we had a Zig->Rust transpiler maybe it would produce similar output. But I can’t find one. We’d have to use an agent to build one first :)

nirui2• 3 days ago

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 change the world for the better.

Think of it as a democratization of technology. You don't want Microsoft stealing your data? Just ask a AI to write an OS for you. You don't want Google to listen to what you're saying? Just ask a AI to design a phone for you. If one day the AI ended up doing that, it will be the ultimate technology self-sufficient. In front of that, your job security is insignificant.

It is also why keeping the tech open source is that much important. Otherwise, it's still the same old shit again and again, and, you lose your job too.

phinnaeus• 3 days ago

I'm a developer

Then you must know that the hardest part of software development is getting clear requirements...

everyone on this planet could create a software for themselves exactly as how they wanted

Even with perfect AGI this will never happen because people will never be able to express clear requirements

William_BB2• 3 days ago

It's not even about requirements. It's about responsibility. Someone has to take responsibility for the code and the product. Someone has to hotfix a bug that's costing millions of dollars an hour and someone has to be blamed for a bug that's consting millions of dollars an hour.

slekker• 3 days ago

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!

revengerwizard• 3 days ago

It definitely worked as a marketing stunt for sure

anematode2• 3 days ago

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

nirui2• 3 days ago

That's why it matters for people to hold the control of the tech, not companies, as I've already mentioned quite clearly.

LLM is here to stay, keep denying the fact won't work. What does is to make the tech so abundant, it flushes the bad actors, such as for-profit AIs, completely out. It's either this, or get crushed by for-profit AIs, pick one.

hvb2• 3 days ago

A good tool, in the hands of a skilled craftsman gets great results.

The same tool, in the hands of someone that doesn't know how to handle it? I'll let you finish that

Basically, a good developer can handle the tool better by asking the proper questions, setting good guardrails and tweaking the output where needed

Aeveus• 3 days ago

Anecdotal, but I’ve been getting segfaults in Claude Code. I run inside Kitty tabs, and the entire tab becomes unusable when this happens. No response to inputs at all from that point.

When this happens, a link shows up to report the issue. It’s not clickable (likely due to the segfault), and perhaps more important: it’s encoded, so you can’t see what you would be sending in your report.

Hope it gets better.

mort962• 3 days ago

What makes you think it's a segfault? Does your shell print "Segmentation fault"? If so, you should be back at your shell and you should be able to recover the tab by typing 'reset' + enter (even if you can't see anything as you're typing it).

If nothing prints "Segmentation fault", this just sounds like a hang

javawizard• 3 days ago

I just had this happen today. It was indeed a segfault.

From what I could tell it looked like it was in JS code that had been JIT compiled. I haven't attempted to troubleshoot further beyond setting all my future Claude Code instances to pipe their stderr to disk so that I don't lose the stack trace next time.

MitziMoto• 3 days ago

Something similar has been happening to me with Ghostty, but there is no error message or link and it only happens when Claude uses it's interactive questions interface.

It becomes completely unresponsive to any input except scrolling. I can't select options or even cancel out.

(I am in no way implying this is related to Bun)

nerdix• 3 days ago

I run Ghostty and Claude Code on a work macbook and I haven't seen this yet.

I actually used to have issues with run away memory leaks causing my computer to hang which often required a reboot to recover from. I haven't experienced that in a couple of weeks now. Too early to say just yet but I think its definitely possible that the rust port fixed a bunch of memory leaks that have tangibly improved the experience atleast for me.

Philip-J-Fry2• 3 days ago

Segfaults were a thing with the Zig version. Purely based on the fact it's a line by line translation of the Zig code to unsafe Rust, all the Zig code that caused segfaults is going to also cause segfaults in the Rust version. The Rust code won't fix it until they get to the point of refactoring it into idiomatic and memory safe Rust.

vips7L7• 3 days ago

But if the segfaults are new that implies it’s from the LLM no?

root_axis• 3 days ago

Same experience I have with bun in general. As an idea, it's the absolute best js runtime by a very large margin, but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)

nicce3• 3 days ago

but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)

In Chrome or Firefox, a segfault is usually automatic CVE and in most cases a bounty of thousands of dollars…

roundabout-host• 3 days ago

I have a better idea: convert it to a prompt and commit the prompt to the repository. Then Mythos will be your compiler.

iririririr• 3 days ago

the whole Ai skit is anthropomorphing the compiler as a coworker.

GuB-422• 3 days ago

Why all the mess with Bun?

Couldn't they have rewritten Claude Code in Rust directly? No more need for a JS runtime, better performance, etc... If their agents can do Zig to Rust, why not JS to Rust?

jeremyjh2• 3 days ago

I know, its so confusing. Its almost as if the bun rewrite to Rust has absolutely fuck all nothing to do with Anthropic's product strategy.

59nadir4• 3 days ago

Well, yeah, it's just good marketing and Bun ultimately doesn't matter anyway, not to the wider ecosystem and especially not to Anthropic. The only purpose Bun had for Anthropic was as a way of getting attention, so that's what they used it for.

tbrockman• 3 days ago

In isolation, yes, that does seem like it would have been the better decision for Claude Code, but it also would have severely diminished the value of their Bun/oven.sh acquisition.

Claude Code isn't the only user of Bun (it's probably not even the only user of it internally at Anthropic), and this way they get to keep the Javascript runtime (and other tooling) that their coding models may one day, if not already, prefer to use when given the opportunity. For those kind of apps, you'll probably also eventually find that--what do you know!--Anthropic also has their own cloud offering (instead of Bun being the one to build one) that specializes in running and managing those applications for you. Even if all they get is a community of developers that choose to use Bun over other options, that gives them power and seats at tables they wouldn't have if they just rewrote Claude Code in Rust.

That'd be my best guess, anyhow.

ozozozd3• 3 days ago

So they had to rewrite Bun instead of Claud Code because they “already had bought Bun.”

This thread is filled with non-sequiturs.

aurareturn6• 3 days ago

Is Claude Code bottlenecked by performance?

I think a JS runtime is fine because the ecosystem of tools is very large and plugins are easy.

thewhitetulip6• 3 days ago

Why is ecosystem of tools and plugins a bottle neck when they literally own Claude models and as per their boss, code is so cheap that anything us just an English sentence away?

snek_case2• 3 days ago

People widely report very high memory and CPU usage.

Not all of the memory usage is the fault of Bun/JS. Some of it is likely memory leaks (holding on to data it shouldn't). However, some of the blame does go to using JS. In Rust you can tightly pack your data if you want to, but in JS you can't have nested structs for example. Every object referencing another object is two separate chunks of memory, each with a header, and a pointer from one object to the other. GCs also use more memory. The overhead adds up.

Building a CLI program in JS is a bad choice, and nobody should be defending this decision. Especially since Claude Code is very much able to write Rust code, and they've shown it can port code. Just port Claude Code to Rust directly.

kingds• 3 days ago

it does seem to be very much bottlenecked by performance, yes. very slow to start up, for example.

weakfish11• 3 days ago

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.

ljm3• 3 days ago

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.

senderista• 3 days ago

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

myaccountonhn• 3 days ago

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

vmg125• 3 days ago

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.

blt• 3 days ago

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

LtWorf11• 2 days ago

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.

dmix• 3 days ago

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

ozgrakkurt• 3 days ago

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

johnfn• 3 days ago

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?

weakfish11• 3 days ago

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

ronniebasak• 3 days ago

this. /s

loosescrews• 3 days ago

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• 3 days ago

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

switz• 3 days ago

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.

galangalalgol3• 3 days ago

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.

tripleee3• 3 days ago

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

burner54828182• 3 days ago

“It largely works”

A ringing endorsement!

coldtea7• 3 days ago

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.

pjmlp8• 3 days ago

So Claude isn't great for everything?!?

adastra22• 3 days ago

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

yojo2• 3 days ago

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.

groundzeros20155• 3 days ago

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.

reinitctxoffset• 3 days ago

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

femiagbabiaka• 3 days ago

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

realusername• 3 days ago

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.

geraneum• 3 days ago

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.

losvedir• 3 days ago

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?

solid_fuel• 3 days ago

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.

wonnage• 3 days ago

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.

tacitusarc• 3 days ago

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.

vips7L7• 3 days ago

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

DoesntMatter22• 3 days ago

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

behnamoh• 3 days ago

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

ozozozd3• 3 days ago

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.

LtWorf11• 3 days ago

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?

overgard2• 2 days ago

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.

voidhorse• 3 days ago

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.

sroussey• 3 days ago

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

qudat2• 3 days ago

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

hellohello2• 3 days ago

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?

delusional• 3 days ago

Ncurses is how people used to do it.

qudat2• 3 days ago

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.

tredre3• 3 days ago

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

fny• 3 days ago

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.

nozzlegear3• 3 days ago

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

amoss• 3 days ago

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.

pjmlp8• 3 days ago

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

newswasboring• 3 days ago

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

cozzyd2• 3 days ago

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.

deadbabe• 3 days ago

Should have done it in C++ with SDL3.

onetrickwolf• 3 days ago

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.

simonw22• 3 days ago

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.

vips7L7• 3 days ago

I thought maintenance was free with LLMs???

groundzeros20155• 3 days ago

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

antonvs2• 3 days ago

To the man with a hammer…

tokioyoyo2• 3 days ago

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.

jchw• 3 days ago

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• 3 days ago

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.

bushbaba• 3 days ago

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.

rafaelmn• 3 days ago

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

kccqzy3• 3 days ago

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.

frollogaston5• 3 days ago

Python was faster to iterate on than Haskell even before LLMs

vintagedave• 3 days ago

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

simonw22• 3 days ago

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

keeganpoppen• 3 days ago

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

miroljub• 3 days ago

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.

api• 3 days ago

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.

yoyohello13• 3 days ago

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.

abc422• 3 days ago

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

frollogaston5• 3 days ago

Code verbosity and complexity still matter with LLM coding

pianopatrick3• 3 days ago

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

simonw22• 3 days ago

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.

frollogaston5• 3 days ago

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.

jmspring• 3 days ago

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.

scrollaway7• 1 day ago

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.

golergka• 3 days ago

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

onlyrealcuzzo• 3 days ago

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

mischief6• 3 days ago

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

lmm• 3 days ago

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.

preommr• 3 days ago

I love bun - although disliked how Jarred did the conversion.

Project-wise, nothing has changed.

Bun was always great because of the fantastic dx - it was just really easy to use , with stuff like out of the box typescript (unreal that it took so long for node, and it's behind a super long flag, wtf...). And it didnt have the weirdness of deno, it maintained backwards compatability with node api, and it just worked.

But it was never stable. You'd have to be fool to believe that a single project could stably do everything bun covers. It's always been an insane project. It was built on top of zig, a langauge that hasn't reached 1.0, and is constantly changing, and throw in how he was rewriting his own custom zig stuff. Like c'mon, let's apply some common sense here.

For me, little has changed. I am still going to use bun as a nice dev tool, and use node for production.

hmokiguess• 3 days ago

pi runs in TypeScript and I like it, the target language of the tool, for me, matters only such that I can extend it. I like writing extensions, plugins, things, in TypeScript so I'm cool with that!

Claude Code is closed source, doesn't let me extend it beyond hooks, and these I write in bash anyways.

That all said, why should I bother about this change? Feels like a nothing burger to me, as an end user. This should matter more for those that are internal to Claude Code and Bun developing it.

delegate• 3 days ago

I'm looking at this situation strictly as 'What's possible today'. If a 1M lines code rewrite from one language to another goes into production in 1 month, that's a very strong signal that the models are now insanely capable.

My anxiety before merging a 2K lines PR is greatly reduced after 3 frontier models (Fable, 5.6 and kimi K3) finds no issues in it.

Just 6 months ago (Opus 4.6) this was not true, a big PR would have countless number of issues.

Aside from the human drama, the message to all of us is - these things are ready for whatever your imagination can throw at them.

I think that's exactly what Anthropic wanted to communicate.

rzmmm• 3 days ago

It was not really a traditional rewrite. More like transpilation. Still impressive

dgellow• 3 days ago

Aside from the human drama, the message to all of us is - these things are ready for whatever your imagination can throw at them.

…if you have the compute and capital to run that whole agentic system

throwatdem12311• 3 days ago

I despise this era we live in. Pushing rewrites like this upon millions of users, when the Bun rewrite has countless known issues and is likely a security nightmare. Every time I ‘brew outdated’ and I see a wall of updates I die a little inside knowing that most of this code has not been verified or even looked at. Yet we hear about massive supply chain attacks pretty much every week now and we’re still full steam ahead on this vibe coded nightmare. God help us. Claude Code in particular updates sometimes multiple times per day. Like I’m sorry but there is no way all this nonsense is safe.

zuzululu• 3 days ago

as it always should've been Rust was the right move

larodi• 3 days ago

Ok, so let me wrap this for everyone:

While everyone here in this forum kept arguing (and fighting and yelling at each other) whether tis moral/right/secure/cheap for ppl to rewrite and ship a major software package with LLMs/agents, one of the main drivers behind AI actually did it, without consulting your opinion, and most same everyone actually slurped this decision without paying a a notice.

Boring is good, but this boring is super massive major thing that happened, and precisely because security is still intact.

luciana1u• 3 days ago

a terminal app now has a supply chain long enough to include a runtime acquisition. somewhere between "rewrote it in Rust" and "ship it" someone said "or we could just buy the company"

jason_s• 3 days ago

TIL about Bun.

lykahb• 3 days ago

Is it easier to rewrite Bun than it is to rewrite Claude?

mrothroc2• 3 days ago

Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust.

Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.

Rust does this automatically. It removes an entire class of errors from his backlog. From an engineering management perspective, this looks like a pretty good trade.

The bonus here is that compiler errors are exactly the kind of deterministic guardrail you need to put around coding agents. Claude works really well if you give it a way to test for correctness and "make it compile" is a pretty good target.

There's a general version of this: the artifact you expose plus the test you run on it. Deterministic tests turn stochastic output into a hard guarantee. Wrote it up here if useful: https://michael.roth.rocks/blog/verification-surface/

awesan2• 3 days ago

Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things".

You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (like what llms generally prefer), it doesn't make sense to use it.

hugmynutus2• 3 days ago

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 this). Instead of using a language with builtin guarantees & optimizations around handling this so your object pools don't need to carry around a bunch of function pointers. C++ has aggressive de-virtualization passes so at runtime a lot of the 'complex object hierarchies' can be flattened to purely static function calls.

kllrnohj4• 3 days ago

You can just do that, and then Zig is really no less robust than Rust.

If you just don't write bugs, then yes all languages are equally robust, including assembly.

Zig, like C, is simply not a robust language. I don't know why this feels like something contentious? It's clearly not intended to be robust?

cyber_kinetist• 3 days ago

I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.

You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)

hresvelgr3• 3 days ago

You can just do that, and then Zig is really no less robust than Rust.

That's just it, using Zig required more rigorous engineering than the Bun team were capable of.

Jarred• 3 days ago

Grouped and arena allocations work really well in Zig. For awhile, we tried to use this pattern almost everywhere in Bun but it gets really tricky when there’s some GC-managed memory and you want to free things incrementally to reduce RSS. Also, using arenas for arrays that grow wastes memory a lot since it keeps every previous version around (mimalloc arenas are slightly better for this)

Grouped allocations works especially well in parsers & ASTs where the lifetime is very bounded. Since the Rust rewrite, we still use arenas for Bun’s parsers and the bundler but not a ton elsewhere.

eddd-ddde• 2 days ago

Zig is always _less_ robust than rust. Even if you have a single allocation you can always forget to free it.

latortuga• 3 days ago

I seem to recall this Rust rewrite is all "unsafe" meaning it really doesn't automatically eliminate those issues.

mrothroc2• 3 days ago

Relevant passage from Jarred's post:

"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."

nsonha• 3 days ago

what is surprising about it? The way porting works has alway been first doing a faithful pass before going back to address impedance mismatches case by case. You would do that even when porting things manually, let alone in a super risky completely automated bulk migration.

BearOso• 3 days ago

Rust does this automatically.

A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.

Diggsey• 3 days ago

You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated.

Ownership is automatic. You don't have to explicitly drop things when they go out of scope. (although the responsibility for that is split between the compiler and the library code).

Lifetimes are not automatic, but also have no effect on memory allocation. They are purely a static analysis path and you can make a functioning rust compiler that completely ignores lifetimes.

gcr3• 3 days ago

It’s my understanding that bun was ported to unsafe rust, so even these gains would require additional effort on the team’s part, right?

smolder• 3 days ago

You don't need to rehash the same old argument. Runtime memory management is forgiving but also inferior in a lot of ways to compiled stuff that works with memory deterministically.

Garbage collection is a method to make programming easier, not to make the resulting program better.

gchamonlive3• 3 days ago

Rust does this automatically. It removes an entire class of errors from his backlog.

Even with the huge amount of "unsafe" rust currently in bun? https://news.ycombinator.com/item?id=48967630

theshrike792• 3 days ago

You think it’ll all stay there?

Of course they’ll iterate and remove the unsafe bits which were necessary for the transition

zamadatix• 3 days ago

As opposed to every commit abd line of code being unsafe? They use a lot of C/C++ libraries with their own code so unsafe isn't even a a problem in most places they use it.

nestorD• 3 days ago

Fun fact, unsafe does not let you turn off the borrow checker in Rust: https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...

portly• 3 days ago

LLMs catch memory bugs quite easily in my experience.

All of this is just a (succesful) marketing stunt by Anthropic.

bluegatty• 3 days ago

Good thing there are tons of languages that do that out of the box, and which are frankly quite fast.

m00dy• 3 days ago

Rust is the clear winner of LLM era, you can't say otherwise.

zombot5• 3 days ago

"make it compile" is a pretty good target.

But only as far as "make it compile" is a good predictor of runtime behavior. In C++ for instance, I can "make it compile" and it still crashes at runtime or does other undesirable things.

raverbashing• 3 days ago

He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.

Yes, and again the "you're holding it wrong" people or "you are not a good enough developer" people will try to do juggling with a chainsaw and lose a couple of fingers in the process

Claude Code's endorsement (and real-world testing) speaks louder than internet discussions that are at this point 30 years old (and probably more)

boutell• 3 days ago

I thought that this was just an initial translation to unsafe rust in which they haven't actually gained any of those benefits yet, although presumably they can go there quickly now.

kimjune01• 2 days ago

i found the same thing with Rust, verification steps are really helpful for speed and correctnesss

Nimitz14• 2 days ago

Ai slop

23951276• 3 days ago

Basically Anthropic can ship any trojan in underhanded Rust to any target because it is not possible to audit 1M lines of slop.

And the crowd is cheering.

rekttrader• 3 days ago

They’re just wildly successful terrible engineers who can describe problems well and have unlimited token budgets. If they were paying for their own token use, the software would be better, they simply don’t have financial incentive to be more performant.

A dirty secret of AI data centers are that they’re only getting 40-60% efficiency out of their GPU clusters and because the moneygun go brrrrr they just buy more.

You wonder why they’re so afraid of the Chinese competition… they can’t afford to be as wasteful

DWe1• 2 days ago

Describing problems well may be one of the most important skills an engineer can have.

steveiliop56• 3 days ago

Ah so that's why it has been crashing constantly for me.

harrisi3• 3 days ago

Maybe I'm taking crazy pills, but I swore there have been very similar comments I've seen as the current top post by 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.

It turns out, there's some similar sentiments in the last year ish:

https://news.ycombinator.com/item?id=47043325

https://news.ycombinator.com/item?id=47105720

https://news.ycombinator.com/item?id=48001113

https://news.ycombinator.com/item?id=46134570

https://news.ycombinator.com/item?id=46124596

I'm not a fan of any of the technologies, companies, or people related to this. I just couldn't shake the feeling that I've seen similar comments.

September and all.

harrisi3• 3 days ago

I don't want to edit this to change the narrative, but I wanted to clarify that I'm not not a fan of all of the technologies or people related to this. As far as compan{y,ies} go, though, well..

vdfs• 3 days ago

Maybe because the 1st thing any experienced technical person would think about? It's like rebuilding and optimizing the racing track to make F1 run faster.

harrisi3• 3 days ago

Perhaps. The thing I was trying to highlight more is comments (particularly disapproving ones) about the intersection of JavaScript (especially React, apparently), TUIs, and LLMs.

I just thought it was interesting. I'm a fan of TUIs, both positive and negative about JavaScript (the modern language is quite nice, given you avoid the historical warts, in my opinion - the ecosystem is unfortunate), and I think the best description for how I feel about LLMs is that I'm bearish. Also Simon is a fantastically prolific and intelligent person though, even though LLMs are not my cup of tea.

https://news.ycombinator.com/item?id=48960912 is a recent comment by someone I also respect related to how LLMs recreate human-like content (Widgets, really), making actual human-created content feel fake.

Sometimes it sure does feel like ELIZA is the main news source these days.

scrollaway7• 3 days ago

I have ~24 years of experience coding and the LAST thing I think about when opening claude code is "why is this written in react".

Tell you what I sometimes think about though: The fact it has clickable links and complex formatting rules for markdown, the most interactive and highest-quality clickable interface I've ever seen in a terminal, and somehow manages to work. That actually blows my mind.

THEN, I'm reminded that it's written in React, and I think "Huh, guess that does make it a ton easier than using ncurses or something."

And done.

dundarious• 3 days ago

What's the implication or inference based upon this? So you're seeing comments sharing a general attitude. And?

As it is now, your post is meaningless to me.

lionkor2• 3 days ago

It's because rewrites are almost always a bad decision. Best case, it's a naive decision made by people who don't know better, worst case it kills the product (who here uses netscape?).

So, from the start, people will be skeptical of a "we rewrote xyz in Rust" because it rarely works out. But there's a lot more to this, in fact it's a little bit loaded with "tech bro" ideas:

- Rewriting in Rust

- Rewriting using AI

- Making terminal apps in JS

- Zig (a lot of people's dear language) is involved somehow

This attracts every single skeptical developer. The only thing missing is maybe blockchain, if that was still cool. It just hits all the "what? why?" spots.

I was already writing a comment, when I realized that what I wanted to write had already been said by the top comment. I suppose that's why comments read so similarly.

Debo_Jolaosho• 3 days ago

For real

LAC-Tech• 3 days ago

Has all of this drama turned anyone else a bit sour on bun?

I have a long running side project I migrated to bun, and I'm starting to regret it. I don't want to build on top of this much churn.

forrestthewoods• 3 days ago

It’s interesting that Bun was a human rewrite from Go to Zig. (I think?). Then rewritten from Zig to Rust.

AI is pretty good at rewrites and ports. Quite good infact.

effnorwood• 3 days ago

My perl re-write is not very good.

globalnode• 3 days ago

at this point im declaring any "rewritten in X" articles as trolling lol.

jgbuddy• 3 days ago

Why even write Claude code in JavaScript at that point, assuming they write the application logic in node and also include the interpreter in the application?

snek_case2• 3 days ago

Probably because the team lead is a web developer, and whatever he says goes. Companies are typically very hierarchical, even if they like to claim otherwise.

512colors• 3 days ago

you know what i hate? i hate that each update, to codex or claude code, it seems like they're always trying to "hide stuff" , reminds me of the 80s and 90s when tech assumes normal people are too stupid to see 'raw' stuff like terminal commands being run, its always been like that, less so now, but i get so mad when its doing stuff, and i can't see if its deleting files or just screwing something up. btw this is totally free tool buttonscli.com that is a full UI terminal app but its got a button for agent control. You click that, paste into claude code or w/e/any agent, and it'll use that for the terminal commands instead of the built in one so you can see everything (and it can open 10 tabs if it wants, you see them all)

the_black_hand• 3 days ago

I'm stupid and clearly too stupid to google too. Is bun simply a better nodejs? Assuming it true that all of Claude code is now written by AI, why would AI care about using bun over node?

arikrahman• 3 days ago

Why not just use Deno that's made in Rust and also has safety in mind?

quikoa• 3 days ago

How will Anthropic be able to rewrite that in Rust and use it for marketing?

IshKebab3• 3 days ago

Yeah I'm also wondering what the point of Bun is when Deno already exists. Especially since it added Node compatibility. Genuine question, why should anyone use Bun if they're already using Deno?

Saba-Ba• 3 days ago

It was an intersting case. Watched a youtube video about this and discussion from zig founder and bun was a little weird.

foldr3• 2 days ago

Is anyone else failing to understand all the internet drama surrounding this?

The rewrite may work out on a technical level or it may not. Let's wait and see. The Bun project did not swear a blood oath to use Zig forever, and it's ultimately their choice to switch to a different programming language.

Beyond that, people seem to be incredibly emotionally involved with this, for reasons that entirely escape me.

overgard2• 2 days ago

Oh good, the vibe coded prompt injection vector that casually accesses things in my home directory without permission is running on a vibe coded prerelease runtime using lots unsafe rust. What could go wrong?

Claude Code uses Bun written in Rust now

Related Stories