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/
weakfish 3 hours 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.
switz 2 hours 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.
coldtea 2 hours 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.
KronisLV 1 hours ago [-]
> 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 48 minutes ago [-]
Can't have been that cheap if they thought buying Bun for an undisclosed amount of money was cheaper.
pdimitar 42 minutes ago [-]
> 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 18 minutes ago [-]
> $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.
pdimitar 9 minutes ago [-]
Yep, same thought. And it seems Anthropic agrees.
weakfish 1 hours ago [-]
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.
pdimitar 50 minutes ago [-]
> 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".
harrisonjackson 24 minutes ago [-]
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.
tripleee 2 hours 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!"
benoau 2 hours ago [-]
> They succeeded in spite of their tech choices.
Or those choices just don't matter, it's fundamentally just "tabs vs spaces".
pdimitar 35 minutes ago [-]
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).
azeirah 1 hours ago [-]
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 1 hours ago [-]
> 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 41 minutes ago [-]
That may be so but Claude code certainly has rendering glitches in other terminals too.
anamexis 2 hours ago [-]
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 2 hours ago [-]
for about half a year claude code had this obnoxious flicker problem. i almost quit and went to codex over it.
nozzlegear 2 hours ago [-]
> 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 21 minutes ago [-]
I think the point is that people still continued to use it above everything else regardless.
enraged_camel 2 hours ago [-]
>> 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.
galangalalgol 2 hours 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.
weakfish 2 hours ago [-]
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.
bwfan123 2 hours ago [-]
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.
jeremyjh 2 hours ago [-]
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.
galangalalgol 2 hours ago [-]
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 2 hours ago [-]
They decided on the tech stack for Claude Code over a year and a half ago.
simonw 2 hours ago [-]
I'm going to guess Anthropic are OK with "fully dependent on AI to fix whatever breaks".
jubilanti 2 hours ago [-]
> 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 2 hours ago [-]
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 2 hours ago [-]
The era in which the [VC-backed, SV area] tech industry built software to last was over long before LLMs.
yojo 18 minutes 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.
yojo 15 minutes ago [-]
Oh, and the memory use! I run a lot of concurrent sessions. 3 gigs for a terminal window is ludicrous.
adastra22 29 minutes ago [-]
Claude code still can’t handle scrolling history without corruption. It is embarrassingly broken.
burner54828182 2 hours ago [-]
> “It largely works”
A ringing endorsement!
pjmlp 1 hours ago [-]
So Claude isn't great for everything?!?
cozzyd 1 minutes 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.
ljm 3 hours 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.
vmg12 1 hours 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.
senderista 2 hours ago [-]
Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?
ljm 2 hours ago [-]
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.
st3fan 1 hours ago [-]
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 2 hours ago [-]
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 2 hours ago [-]
I think the author is saying everything that touches llm.
2 hours ago [-]
myaccountonhn 2 hours ago [-]
Its so wasteful, but that tracks with the modus operandi of AI companies.
johnfn 3 hours 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?
weakfish 2 hours 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
jm4 27 minutes ago [-]
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.
AndrewKemendo 2 hours ago [-]
>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 1 hours ago [-]
>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 1 hours ago [-]
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
weakfish 2 hours ago [-]
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.
Code is the killer app for LLMs so software developers are the easiest to replace.
weakfish 1 hours ago [-]
Code isn’t what the majority of software engineering is.
Kiro 30 minutes ago [-]
Pointless nitpicking that completely missed my point. Software developers are not the hardest to replace, so your presumption that everything else should be easier is wrong.
AndrewKemendo 1 hours ago [-]
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 1 hours ago [-]
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.
ronniebasak 2 hours ago [-]
this. /s
dmix 3 hours 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
newswasboring 10 minutes ago [-]
Anything that can be written in JavaScript will be written in JavaScript. That's just how it is it seems.
2 hours ago [-]
hellohello2 2 hours 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?
tredre3 1 hours 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).
qudat 2 hours 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.
delusional 2 hours ago [-]
Ncurses is how people used to do it.
sroussey 2 hours ago [-]
So the code for the web, the desktop app, and the cli where largely similar.
qudat 2 hours ago [-]
The component trees have to be rewritten, only the non-view related JS code can be reused.
3 hours ago [-]
voidhorse 2 hours 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.
ozgrakkurt 3 hours 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”.
fny 2 hours 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.
amoss 1 hours 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.
pjmlp 1 hours ago [-]
There are several compiled languages with live reloading, including C++.
nozzlegear 2 hours ago [-]
There's no surgery when you're a company with a trillion dollar hammer and every problem looks like a big ass nail.
lykahb 49 seconds ago [-]
Is it easier to rewrite Bun than it is to rewrite Claude?
gabrieledarrigo 7 hours 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?
baq 7 hours ago [-]
I guess the point is none of it matters, CC users didn't notice or don't care except an exceptionally small minority.
6 hours ago [-]
conartist6 7 hours 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"
zarzavat 6 hours 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.
nicce 5 hours ago [-]
> 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.
Is there a huge need to run that typechecking on browsers?
conartist6 5 hours ago [-]
First, yes, the demand to be able to code natively in a browser is, I have reason to suspect, very large. It's just difficult to measure demand when nobody has ever offered a really compelling product. In engineering terms it's like getting a full-scale reading. The real level could be 1% above a full-scale reading, or the real level could be 100x higher than the full-scale reading.
Secondly, WASM isn't the right target for the browser anyway, JS and the DOM have to be what you consider "native", for the most rigorous UI projects at least (which building an IDE is). If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
skydhash 2 hours ago [-]
> If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.
conartist6 54 minutes ago [-]
All great examples, but ones that do require installation. Their website is just where you download the product, I'm talking about making the website the product.
It's not just typechecking, the typescript library is also the reference parser for TypeScript and reference emit. Emitting JS from TypeScript is non-trivial and non-local.
It's not just in browsers, you might want to run the typescript library on the edge or in some restricted environment where JS/WASM is OK but native code is not.
You may want to use the typescript library as a dependency in your own package. TypeScript becoming non-pure JS means that your library also becomes non-pure JS.
anon7000 3 hours ago [-]
NodeJS can strip types internally without a straight TS dependency. I don’t think this matters, TS was a huge bottleneck for many build pipelines because it never parallelized well
shepherdjerred 1 hours ago [-]
It is incredibly useful
6 hours ago [-]
CrimsonRain 2 hours ago [-]
[flagged]
amazingman 2 hours ago [-]
Normal users, anti-AI dinosaurs / zig fanatics, and no one else. That's a nice echo chamber you have going there.
Sammi 2 hours ago [-]
"Normal users" haven't even heard of Bun and are still on Node.
embedding-shape 8 hours 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?
junon 7 hours ago [-]
Why does changing to Rust kill the project? I don't understand the point here.
atonse 7 hours 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.
jasode 7 hours ago [-]
>Literally who cares what language a JS toolset is written in?
Maybe you're being coy by asking a rhetorical question you already know the answer to but I'll answer as if you asked sincerely...
There are 2 different groups interacting with software products:
(1) end-users : this is where the "Who cares what language it's written in?!?" is usually applicable. E.g. The finance guys using MS Excel don't care whether it's written in assembly, BASIC, or C Language.
(2) code contributors and/or programming language enthusiasts who see other projects as "validation" of the whatever language they've invested in: these people definitely care.
For all the decades that computer languages have been debated, Group (2) will always discuss projects language choices. E.g. reddit.com switching from Lisp to Python, the Linux kernel fiercely debating future Rust contributions , the Typescript compiler switching from Javascript to Go, Bun switching from Zig to Rust, etc.
People try to lecture others in Group 2 about "don't make a programming language your identity" ... but people are human and they can't look at all the above language choices as totally detached observers. They like to talk about it!
If one is a Zig coder that contributed to the previous Bun Zig codebase, we can't expect them to be neutral observers.
estearum 6 hours ago [-]
I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity."
There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Group 3s in every similar convo, for any combination of technology, project, and acquirer you can name.
atonse 2 hours ago [-]
I think most of the naysayers are in group 3 because there’s a lot of anger but never a single link to a blog post or analysis done by anyone to demonstrate a regression. not one. There are some that analyzed the quality of the initial rust code and use of unsafe but Claude has been chewing through those as I understand.
It was a PR issue more than anything else. It is also a proxy for Pro AI and Anti AI sentiment.
And for most part I don't think it was communicated well apart from the last blog post.
rjzzleep 6 hours ago [-]
What about Group x.
You just AI generated 1 millions lines of code claiming it's for safety. Who exactly is to make any kind of security guarantees about this?
2 hours ago [-]
2 hours ago [-]
conartist6 5 hours ago [-]
Don't forget the group asking really dumb pointless questions like "who legally owns the rewritten code"
ethbr1 4 hours ago [-]
Afaik, under current US law (Thaler v. Perlmutter 2025^), "the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being".
With regards to AI-generated code, this means the copyrightability (at all, not with regard to who owns it) turns on whether or not a human was substantially involved in its creation.
Existing decisions require evidence of pretty heavy and continued human guidance to qualify.+
To wit, autonomous agent created code (prompt -> machine churns for hours -> output) is explicitly not eligible for copyright.
Functionally, this is a double-edged sword.
On the one hand, it means anything coded with autonomous agents by Meta, Google, et al. can be legally reused if it leaks (because no one could hold copyright on it).
On the other hand, it leaves copy-left open source licenses in a weird place. If you convert open source (even MIT/BSD-style) code into something else with an autonomous coding agent... the result has no copyright (nor can ever in the US).
In this instance, Bun was MIT-licensed, no? Then it was shoved mostly-autonomously through an LLM for the port.
Now Bun-Rust is technically still MIT licensed, but if push came to shove it seems like US law's current position is that Bun-Rust would now have no copyright license (because the manner in which it was developed renders it ineligible for copyright).
That's on the copyright side.
On the infringing usage side (i.e. whether you were entitled to shove a copyrighted work into a coding agent to produce something)... that's still TBD.
> who cares what language a JS toolset is written in?
Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues.
doctorpangloss 3 hours ago [-]
imagine being the leadership of the one of most valuable US private companies in the world. then you have to make something called a "pull request" that gets "reviewed" by someone named "Jarred" to make improvements to your stuff. do you see how that is untenable?
the language is relevant for political not technical reasons. you could say, blanket closing the Issues, getting rid of this thing called Jarred from your stack, etc., is really an attack on the GitHub and the GitHub Agitator Lifestyles, which is why so many commenters on Hacker News actually care.
skybrian 5 hours ago [-]
[dead]
3 hours ago [-]
bmitc 3 hours ago [-]
The outrage was more how the rewrite was communicated and defended, which was objectively poor.
jgalt212 5 hours ago [-]
> It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it.
> poster child for Zig programming language actually being the prime example of How Not To Write Zig Code
> 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?
And this is a valid question. You are not "defending reality" by refusing to listen to it.
In summary and based solely on my understanding:
- Jared misled people about the intentions of the migration. It's not the worst thing in the world, but it's certainly worthy of criticism.
- Jared has commented before about locking out human contributors from open source projects. Whether he was making a larger point is irrelevant as his comment stands on its own.
- Other Bun contributors, past and future, outside of those employed by Anthropic, did not and likely will not have equal access to the model Jared used for the rewrite.
Jared, working in the public Bun repository, used tooling not available to his community to experiment with a signficant migration. He dismissed all concerns and told people it's just a bit of fun, and that it shouldn't be taken seriously. Most of the controversy would have been avoided were the experiment done in private.
None of this is a big scandal but questions about the project are entirely justified.
cube00 5 hours ago [-]
> I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
Similar to the Claude Code 60s timeout incident [1] it could just be "Jarade decides what gets done and accepted"
Except that it hasn’t yet hit the real world, the live release is still 1.13.4, the last Zig version. Anthropic does not operate in the real world.
Tadpole9181 3 hours ago [-]
The canary build has been Rust for over a month, available to anyone. In that time it has been used in production for Claude Code and Prisma Compute.
atonse 2 hours ago [-]
Not sure why this purely factual post got downvoted. Upvoted it.
zzzeek 4 hours ago [-]
this whole AI era has put the topic of "do we believe actual reality, or what we hoped/assumed/continue to insist would be reality" front and center. Every discussion is like this these days.
re-thc 6 hours ago [-]
> that this made bun worse in any measurable way
Issues on GitHub was mass closed claiming zig is no longer relevant without fixing the real issues.
atonse 2 hours ago [-]
Whole classes of bugs WERE fixed by moving to rust. wouldn’t that result in mass closures of classes of bugs that were no longer relevant in rust? What would you prefer?
re-thc 11 minutes ago [-]
I would prefer they confirm before closing. It's AI / bot anyway. Instead it's just mass keyword zig = close. The bug can still exist post-port. None of it got "fact-checked".
In fact a lot of "feature requests" like npm compatibility related or missing specs etc ALL also got closed for being "zig" because reproduction and suggested solution were of course zig.
Again doesn't mean it got "auto fixed".
well_ackshually 7 hours ago [-]
There's two kinds of reliable open source projects:
* Open source because it ticks a checkbox but is only being really developed by a large team paid contributors and your changes (see: Chromium, most of Linux, Node, etc.)
* Open source because of belief that sharing it publicly will do good and collaboratively built by a very small group of core maintainers and others wanting to improve it.
Bun is now solidly into the third, absolute shit category: very small development team headed by a tech bro that shits out millions of lines of code he doesn't even know how they work and will inevitably collapse under its own weight while he swaps things out from under your feet.
It's not a language issue, it's a trustworthiness issue, and Bun was already pretty low in trust even before the Anthropic acquisition. In addition, we now have Claude Code running an unreleased version of Bun, for a while now: Bun is effectively not even open source anymore, just a source code dump from time to time.
CrimsonRain 6 hours ago [-]
What a load of bs.
> Inevitable collapse
According to who? You? The well ackshually guy?
> Low in trust before acquisition
Cite your sources.
> Unreleased version
v140 is the canary version which has been available for a long time.
What is actually going on with that tag? It has files uploaded in Jul 29, 2024 and files uploaded "6 hours ago" (some hours after Simon first published his blog post). Do they not do proper releases with immutable tags and instead use one tag kind of like a git branch that mutates and changes over time?
simonw 5 hours ago [-]
Yeah, it looks like they constantly repoint the "canary" tag at whatever they think should be the new canary release.
I don't like that, personally. I think the project would be easier to reason about if they shipped alpha versions instead.
bikeshedpelicun 5 hours ago [-]
[flagged]
simonw 5 hours ago [-]
Did you create a burner account just to accuse me of bikeshedding Bun's release tag process?
stymaar 7 hours 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.
ljm 3 hours ago [-]
> bun was vibe coded by a single dude without any open source community involvement.
I think even this is largely beside the point. The acquisition of any project by Big Capital (whether tech or VC) is usually a killing blow.
Matl 6 hours ago [-]
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
rane 4 hours ago [-]
"Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising.
endospore 4 hours ago [-]
"Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process.
Can't help laughing at this point.
mpyne 3 hours ago [-]
I don't know, did the prior vibe-coded Zig code not ever have pointers aliased to data? Might be preserving semantics too well, if anything.
endospore 3 hours ago [-]
The Zig one uses raw pointers. These are bad and get out of hand quickly but at least don't have constraints like "you must never have two &mut on the same value". You may refer to c2rust to see how "semantics preserving transformation" without new UBs looks like.
uecker 2 hours ago [-]
Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.
Dylan16807 5 hours ago [-]
Surely a lot of review has happened in the last two months?
endospore 4 hours ago [-]
Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated.
Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
Tadpole9181 3 hours ago [-]
This feels like such an absurd, bad faith take I keep hearing.
In Zig, every single memory operation is unsafe.
And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors.
There's too much, sure, but can we at least be honest and reasonable?
ambicapter 2 hours ago [-]
What's the point of rewriting it to Rust if you're going to, on purpose, disable the most prominent benefits of using Rust?
Tadpole9181 9 minutes ago [-]
It isn't disabled, it has exclusions. Now that they have it, they can close the gaps. It was literally impossible to have ANY coverage before, now they are mostly, covered and have an avenue for remediation.
I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good?
Was nobody here for moving billions of lines of JavaScript to Typescript? It starts with declarations, then turn on type checking gradually inside the codebase: piece by piece until done.
skydhash 2 hours ago [-]
I'm not a rust dev. But I've been once asked to take care of a TypeScript codebase and the thing was littered with so many casts to `any`, you're wondering why they bothered with TypeScript in the first place. Some people do choose tech on a vibe and not any real analysis.
endospore 3 hours ago [-]
My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it)
> must interface with C code that has no safe interface
Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2x as many unsafes.
And mind you if you haven't read the code, the vast majority of unsafe blocks in bun are for raw pointer access to local (Rust) objects because their ownership was a mess both before and after the rewrite. Also funnily enough a lot of the access patterns are wrong (in the Rust sense), leading to hundreds of new undefined behaviors.
> be honest and reasonable
Well, well. Talking about dishonest and unreasonable behavior, why is bun releasing a new version before solving any of those glaring issues? I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
Tadpole9181 2 minutes ago [-]
> I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
Except, you know, multiple real companies saying that it is and using it in production. And the fact it closed all known memory leaks. And that nobody has a really pointed to a single actual issue the new version introduced after two months of endless, ceaseless bitching.
I'm also fascinated by all these people upset at Jarred for harming the readability of a codebase they've literally never cared about before it become drama. Bun has almost exclusively been maintained by Oven employees since it's inception.
> Deno for instance have ~0.2x as many unsafes.
A project written ground-up in Rust idiomatically, with a smaller surface area, still has an unsafe footprint within an order of magnitude compared to this automated rewrite from an unsafe language with different practices and known bugs? That's not exactly the slam you think it is.
Dylan16807 5 hours ago [-]
Is the idea that a code base reset makes something stop being open source? Or that the number of people doing the reset matters?
I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language.
avianlyric 5 hours ago [-]
I think the point is that an “open source project” is more than just the code and license, it’s also the community that builds and maintains it.
A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again.
Tadpole9181 3 hours ago [-]
Just so everyone know, Bun is and has always been owned by a YC funded org with full time employees. The overwhelming majority of commits came from them.
Dylan16807 5 hours ago [-]
A reset is very different from not being open source any more. If losing most of the community would mark a project dead in open source terms, then every new project would be dead on arrival. And that would just be silly.
CrimsonRain 6 hours ago [-]
That's just like your opinion...? More power to Jared (and anyone else) if they can "vibe code" useful projects like bun.
_pdp_ 7 hours 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.
petcat 7 hours ago [-]
I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
pmarreck 7 hours ago [-]
Anyone actually using it knows it is better. The C interop is so good that there is no use-case where C is the better option IMHO
59nadir 7 hours ago [-]
You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.
lstodd 2 hours ago [-]
By my own admission I wrote ~100K loc in zig-head. Having a background in linux kernel development of all things I can tell you that Zig is so much better than C or Rust, that I think linux kernel rush to rust is misguided.
pjmlp 1 hours ago [-]
Industry standards, existing team knowledge, use after free story is the same as C already has.
bitwize 4 hours ago [-]
Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are:
> Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage.
There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. Rust is so thoroughly and obviously the correct thing that using anything less correct should be taken as a sign of engineering incompetence.
K0nserv 3 hours ago [-]
> There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic.
This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of them, but “fine” as long as you take extreme care are not interesting to me. I’ve started calling this “simple as long as you avoid all the foot guns” idea the sword juggling fallacy[0].
It’s too bad about Zig because it has many nice ideas, in particular allocators, that I hope Rust or some future language will adopt.
yeah rust has no footguns. just dont try to mix clone with iter.
skydhash 2 hours ago [-]
There are many things in life that are "fine" only when you take extreme care (knives, cars, industrial machinery,...). The thing is something like C has many usages and you can't just say "use Rust" and be done with it. Using Rust is not cost-free.
pjmlp 1 hours ago [-]
There is more to it even, the UNIX and C founders arrived to Go, before retirement, after a few other interactions.
AT&T was the one doing the Cyclone research.
And then we have a bunch of folks assuming they know better about C that its own authors?
phoghed 7 hours ago [-]
If this were true the very small but active community of Zig contributors could just fork it and you could all return to the happy times of not using Bun anyway.
CrimsonRain 5 hours ago [-]
Bun became a thing because it provided some specific benefit to js ecosystem. Zig enabled the rapid development. The people who contributed were definitely helpful but they can still choose to help or not and new people will step up too
OJFord 7 hours 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.
atonse 7 hours ago [-]
You can install it now we with bun upgrade —-canary it something along those lines.
NuclearPM 7 hours ago [-]
I think you’re missing a word or two.
OJFord 58 minutes ago [-]
It's extremely obvious what they meant, even if it/or wasn't a common phone autocorrect typo.
layer8 6 hours ago [-]
Based on comments elsethread, I think what was meant is: You can install it now with “bun upgrade --canary”, or something along those lines.
However, people also report that the canary version doesn’t identify itself as version 1.4.
CrimsonRain 3 hours ago [-]
And GP is full of shit as the main branch is the v1.4.0. it is not "released" yet as it is not finished. It is available as canary version.
croes 2 hours ago [-]
So Anthropic ships with unfinished version of bun.
Doesn’t sound like responsible software deployment
41 minutes ago [-]
2 hours ago [-]
3 hours ago [-]
goo0000fy 7 hours ago [-]
[flagged]
OJFord 7 hours ago [-]
From the article:
> 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.
Which is still true as I write this comment.
simonw 7 hours ago [-]
The code is on GitHub in the "main" branch, it's only unreleased in that it hasn't been tagged with a version number yet.
OJFord 2 hours ago [-]
If it hasn't been tagged with a version yet, how do you know (or what makes you think) it's the same as this 'v1.4'?
simonw 2 hours ago [-]
I don't, but it seems likely that it is given that Jarred said "Claude Code v2.1.181 (released June 17th) and later use the Rust port of Bun".
What motive could he have for secretly maintaining a private fork of Bun that's shipped with Claude Code while simultaneously working on the open source repairs every day?
goo0000fy 6 hours ago [-]
yeah the word "unreleased" makes it sound so mysterious
i am a clankersceptic as much as the next guy and i hate "anthropic" for participating in the murder of innocent people (maven "smart" system, offers them as a provider to the pedo criminal unitedstatistan government)
but this whole "unreleased" framing is just manufacturing drama / lack of knowledge
kelnos 7 hours ago [-]
A charitable interpretation is that the version of bun inside Claude Code corresponds to some recent state of their public git repository, so if you clone that, you more or less get the same thing.
I don't see what it would buy Anthropic to have some sort of secret internal fork with special private code in it.
goo0000fy 6 hours ago [-]
bun upgrade --canary
pjmlp 7 hours 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.
afavour 7 hours 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.
kstenerud 7 hours ago [-]
Why is that even a thing to object to? You're talking as if you placed stock in the bizarre idea that Anthropic would close source the project and start charging for it.
Stay your pitchforks.
afavour 6 hours ago [-]
I wouldn’t use language as strong as OPs but it is against the spirit of FOSS for a corporate owner to use a private prerelease version of their open source software.
I think it’s valid to object to. If 1.4 is good enough to be used by Claude, why not us?
kstenerud 6 hours ago [-]
So you wouldn't, for example, after doing a complete ground-up rewrite, perhaps spend a few months dogfooding it to work out the worst bugs before unleashing it upon the public, thus maximizing your initial velocity by minimizing the blast radius and support requests and triage during this phase?
realo 6 hours ago [-]
It's Anthropic. I am pretty sure they spent time dogfooding it to Mythos or an even more advanced model.
That might even be the reason why they switched to rust.
Don't worry too much.
afavour 6 hours ago [-]
> before unleashing it upon the public
…but they have? Claude users are public, no? If they were dogfooding internally I’d agree with you.
kstenerud 6 hours ago [-]
Yeah. One single project that they control. Not thousands of other people's projects breaking, I'm sure with a ton of HN outcry over releasing "this pile of vibe coded slop" upon the poor populace.
You just can't win.
afavour 6 hours ago [-]
> you just can’t win
You could! You could not release a “pile of vibe coded slop” onto people’s machines. There don’t even appear to be any particular advantages to Claude upgrading early. If there are no one has been made aware of it.
ithkuil 8 minutes ago [-]
The irony. A company building models and tooling to automatically produce code being attacked for using automatically produced code in the very tools that allow people to automatically produce code, presumably by somebody who wants to use their tools to automatically produce code, possibly because they believe that their approach at ensuring that automatically produced code is properly reviewed by a responsible human has to be more thorough than whatever that company does because of course they were going too fast and thus it can't be good
kstenerud 5 hours ago [-]
How do you know it's vibe coded slop? Have you seen the source code?
ethbr1 4 hours ago [-]
> How do you know it's vibe coded slop? Have you seen the source code?
I believe you've just made your opponent's point for them.
kstenerud 4 hours ago [-]
Have I? I believe I've merely chased them around their moving goalposts. When it's closed source, that's nefarious because "they're not sharing" and that's against the whole spirit of open source. When it's dogfooding with a reduced audience, it's "shoving vibe coded slop on people" (this information gleaned through magical knowledge). When that unfounded assertion is called, lo and behold: It's closed source, so bad bad bad! It's called a logical fallacy for a reason.
But more to your point: Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
ethbr1 2 hours ago [-]
More to the point, because you've been chasing them around goalposts, you've both accepted that the question at hand is unknowable precisely because the source isn't available.
> Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
Hell yes, and anyone who trusts one of the AI labs for anything important is insane.
Whether it's their initial mass piracy and then lying about it, dealmaking with the US government, or continually shifting opt-out lines on what they are and aren't training on, they haven't earned the trust to skip the "but verify" step.
Their economic incentives are too transparently aligned with ends at any costs.
well_ackshually 7 hours ago [-]
You're running a closed source piece of software (claude code), running on an effectively closed source piece of software (bun), both of them updated daily by AI psychosis bros.
At this point, charging is the least of your issues.
kelnos 7 hours ago [-]
It may be available to us, in the form of a git checkout of their public repository.
It's true that we don't know exactly which, and whether or not there are any other changes added on, but that is the case for every single release of Claude Code that has used bun.
dgacmu 6 hours ago [-]
It's probably not. I tried to extract the commit hash from the version of bun packaged in claude code. the commit hashes from previous versions resolve, whereas the commit hash for the current 1.4.0 isn't available.
from strings:
bun-v1.4.0
f6d0fcd24abd48061873c2f1a6fb2a67eee487b8
Upgraded.
Welcome to Bun's latest canary build!
This build does have a different way of identifying itself than earlier builds so it's possible this string isn't correct.
(In contrast, earlier builds that I have locally have commit IDs that can be found in the public repo). I don't think it's particularly damning for them to vendor a canary release, mind you.
firesteelrain 7 hours ago [-]
Moving the goalposts?
afavour 7 hours ago [-]
No? I think OP’s comment was very clear:
> 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
There’s no implication that it’s because of the switch to Rust.
firesteelrain 7 hours ago [-]
> The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us.
I was responding to your GP comment. For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
afavour 7 hours ago [-]
That seems illogical to me. We’re only allowed to have one objection to a project and once that’s used up we can’t air another? FWIW I don’t think people have forgotten the original objection either!
firesteelrain 6 hours ago [-]
You can; it feels contrived and very social justice warrior/anti Anthropic (which on HN is in of itself almost a meme now). The main reason was because of the blanket AI move which I could understand.
afavour 6 hours ago [-]
I think your perception of events is pretty heavily affected by personal bias here. Objecting to a hasty AI rewrite of an entire runtime and objecting to violating the spirit of FOSS is “very social justice warrior”?
What?
firesteelrain 6 hours ago [-]
Please re read your original comment. AI rewrite is one thing and objecting to FOSS/non FOSS is a new argument, anti-Anthropic etc is moving the goal posts. The main argument was the blanket rewrite to Rust using Claude.
Now, /you/ are trying to move the goalposts into an entirely different argument.
Very likely it’s just anti Anthropic altogether.
Like I said, a meme.
Anthropic hasn’t done anything wrong but if they move a single inch then people will complain. Perhaps it is just a preview version?
afavour 6 hours ago [-]
Airing two entirely separate objections to a project is not “moving the goalposts”. The original objection still stands! You’re using a phrase you’ve heard in an inappropriate context.
I’m sorry but this is a nonsensical debate.
> Now, /you/ are trying to move the goalposts into an entirely different argument.
You said something and I responded to it. That’s invalid too now? There can only ever be one single objection in a conversation? I’m not permitted to react to the things said? Like I said, nonsense.
5 hours ago [-]
firesteelrain 5 hours ago [-]
[dead]
embedding-shape 6 hours ago [-]
> For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
I'm just one person though, and have no problem with a move to language X, using tool Y, who cares?
For "goalpost are being moved" to be valid here, you have to be able to point to someone saying one thing at one point, then same person putting a different target later. You're folding a huge group of people into one person, when that's not really accurate to do.
Your point being? None of my comments in either of those state that I'm upset about it moving from Zig to Rust?
firesteelrain 5 hours ago [-]
I wasn’t referring to you and rather the general sentiment. Hence, goal posts have been moved again comment.
embedding-shape 4 hours ago [-]
My overall larger point (maybe poorly stated) was that unless you're engaged specifically in a 1-on-1 conversation with someone, accusing a whole community of "moving the goalpost" makes no sense, there is a whole host of arguments and points being made in different directions all the time, by different individuals.
firesteelrain 4 hours ago [-]
I see what you are saying. My comment is rooted in the fact that different people are foregrounding different objections to Anthropic/Bun, and taken together it looks like whatever launches, someone will find a reason to be upset
amazingman 2 hours ago [-]
I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic.
Cthulhu_ 7 hours 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).
flohofwoe 7 hours ago [-]
An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zig). It also might explain why porting from Zig to Rust was done 'on a whim', the actual source code (and the idea of 'original work') never seemed to be all that important to the author (and I wouldn't be surprised if the project does more language-hopping in the future heh).
realo 5 hours ago [-]
I read your link, written by Bun's author and totally get his thinking.
In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun.
In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
ambicapter 2 hours ago [-]
Are you really "doing things securely" when you use as many unsafe blocks as the Rust port of Bun does?
gipp 7 hours ago [-]
I don't think the GP had anything to do with the language change itself. More that it marks a clear point of Anthropic taking ownership and governance of the project in a less open direction.
hoppp 7 hours 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.
7 hours ago [-]
foxes 7 hours 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.
embedding-shape 6 hours ago [-]
> As an open source - community driven project? Have you looked at the repo on github?
FOSS as in FOSS - Free and Open Source Software. Has nothing to do with if it's community driven or not, I'm strictly talking about FOSS.
jeroenhd 7 hours 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.
atonse 7 hours ago [-]
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
waisbrot 7 hours ago [-]
Developer community. "Open source" historically implied that an interested developer might hack on the code and submit their changes. But if the entire code-base is rewritten by the maintainer every year, then there's no developer community.
jdiff 7 hours ago [-]
There were very many open pull requests from the community that were all invalidated overnight for something that same community was assured was merely an experiment.
The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed hard work from hundreds of community members.
CrimsonRain 2 hours ago [-]
None of that is needed. Nobody benefits from all that time wasting bureaucracy/corpo speak. Bun is quick to deliver new features and bug fixes. With this change, the hope is that'll only get faster.
All those PRs can be fed thru Claude and converted to rust and then manual polish can be added.
jdiff 1 hours ago [-]
Bun is riddled with bugs. That's what moving fast and breaking things gets you. It gets you famously bad codebases that are nightmares to work with and slow you down over time as your sins catch up with you. Vibecoding is not enough.
hibikir 7 hours ago [-]
It's like a couple of languages I know where there's still one real owner, and there's no real review, and PRs are unlikely to be merged, even with review: They might be open source, but it's more a source visible thing, because you are never going to get a change in, and the language will change directions at the creator's lone whim. The best you can get at times is "I didn't like your PR, so I implemented the feature you tried to add completely different". Typical community killers.
entrope 5 hours ago [-]
> taking that into production with barely any announcement is what kills off the interest to me.
Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.
muglug 7 hours ago [-]
The language an application is authored in does not matter to me, as a user. I care that it is widely-used (safety in numbers), that it works, and that it is fast.
It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
locknitpicker 7 hours 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.
brabel 7 hours ago [-]
> I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision…
Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime!
The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
CrimsonRain 2 hours ago [-]
A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. That somehow kills the project. ok!
conartist6 7 hours ago [-]
of course they also gave away their own claim to be the copyright owner, but that's neither here nor there ; )
embedding-shape 7 hours 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.
atonse 7 hours ago [-]
The whole point of the outrage was that 1.4 was merged into main. Publicly. So I’m not sure what you mean.
Everything is in the open: PR #30412
embedding-shape 7 hours ago [-]
> The whole point of the outrage
Ok, go ask those people what they think then, I feel no outrage over a project switching language or merging whatever. But when once-semi-transparent projects become more opaque after an acquisition, I'm starting to readjust anything to the project I had in mind.
jdiff 7 hours ago [-]
That PR is the rust rewrite. That's some time in the past now. As of this comment, there is no tagged 1.4 release. This is the present. Anthropic is using apparently a version of Bun that is not publicly available. This is orthogonal to it being Rust-based, as all Bun releases now will be.
That commit (and main) still purports to be 1.3.14, the version numbers haven't changed. Does that not still suggest Anthropic is using something else?
simonw 6 hours ago [-]
I think Bun/Anthropic should document which commit hash their "1.4" as shipped in Claude Code uses.
alexjurkiewicz 7 hours ago [-]
Come on, "not publicly available"? You know how git works right? Each Claude release probably has the HEAD of main compiled as "1.4.0" until there is a real official release.
jdiff 7 hours ago [-]
I do know how git works and in my experience, while the version number sometimes doesn't get bumped until just before a release is tagged, the version number comes from the codebase. If they're building something that says 1.4.0, then they have a codebase that disagrees with ours.
Lerc 4 hours ago [-]
Where is the previous version referred to in the codebase? I'm guessing that would be the place to look for changes.
If you can't find an update at that place in the codebase saying 1.4.0 you can ask where it is. It seems after doing that and not receiving an answer would be the appropriate time to start making the claims that people are throwing around.
v1.4 hasn't been tagged... No idea what the shipped binary corresponds to.
embedding-shape 6 hours ago [-]
Yeah, of course Anthropic making the version publicly available AFTER people notice it wasn't public, completely solves the issue ;)
simonw 6 hours ago [-]
Anthropic changed nothing since I wrote published this post a few hours ago - I updated my post to mention Bun canary since it was a point of confusion here on Hacker News.
So it has been canary since then, most likely, if docs are accurate that latest main is canary.
Lerc 6 hours ago [-]
You seem to be wrong about that
Nevertheless, the principles of open source never demanded more than providing the source upon request.
7 hours ago [-]
minraws 7 hours 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
jdiff 7 hours 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
(Though that doesn't clarify that this is the Rust rewrite)
GuB-42 3 hours 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?
jeremyjh 1 hours 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.
nirui 6 hours 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 5 hours 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_BB 34 minutes 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.
hvb2 5 hours 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
slekker 5 hours 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 5 hours ago [-]
It definitely worked as a marketing stunt for sure
luciana1u 16 minutes 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"
Aeveus 5 hours 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.
nerdix 24 minutes 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.
mort96 5 hours 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 13 minutes 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 2 hours 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)
feverzsj 7 hours 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.
daishi55 6 hours 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.
cube00 5 hours 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.
daishi55 4 hours ago [-]
historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”.
This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.
endospore 3 hours 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.
daishi55 55 minutes ago [-]
Sorry you think they’re not going to continue developing and improving bun and making it more idiomatic?
Given the success of the port so far and the fact that CC is now running on rust Bun, that seems highly unlikely to me.
endospore 16 minutes ago [-]
That's a stated goal, so nope. But releasing it before any cleanups is another story.
I'd also like to inform you that
- the current success metrics solely consist of their advertisement, my eyes looking at the code strongly suggest otherwise
- the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust and relying on model knowledge is already proven insufficient.
The release decision itself is presumably driven by that tbh. It's only LGTM from there when nobody knows how to review unsafe Rust.
variadix 5 hours 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.
brabel 6 hours ago [-]
Can you show some examples of abominable Rust code they have?
alexandra_au 6 hours ago [-]
grep -nr 'unsafe' .
Is all you need to know to consider how much of an abomination it is
simonw 6 hours 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:
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?
endospore 3 hours ago [-]
> The original code was one giant unsafe block
True.
> has fewer bugs
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
William_BB 28 minutes ago [-]
> has fewer bugs
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)
luckydata 30 minutes ago [-]
given enough time and tokens, it will become that. I really don't understand how that is a problem in any way.
amelius 6 hours ago [-]
Why not transpile directly into LLVM IR?
3 hours ago [-]
jqbd 5 hours ago [-]
I don't think AI or humans are trained well on it.
brown9-2 5 hours ago [-]
Is it important to be idiomatic if the project meets its goals around memory safety?
kikimora 5 hours 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.
feverzsj 5 hours ago [-]
If it's not idiomatic, the memory safety won't be guaranteed.
codethief 6 hours 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.
NateEag 2 hours 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.
PsylentKnight 5 hours 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 2 hours ago [-]
Does exiting following by resuming the session fix it?
kilroy123 3 hours 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.
softwaredoug 6 hours 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 :)
jason_s 13 minutes ago [-]
TIL about Bun.
bel8 7 hours 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.
reddalo 7 hours ago [-]
Damn, I should have not migrated to Bun. Should I revert back to Npm?
cromka 7 hours 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?
awestroke 7 hours 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
johnny22 7 hours ago [-]
i assume it's because of all the built in tooling that node doesn't ship with.
vaughnegut 7 hours ago [-]
There's always deno
jqbd 5 hours ago [-]
but it's written in Rust too /s
orf 7 hours ago [-]
What specific technical issues are you experiencing with running Bun that would justify a change?
7 hours ago [-]
6 hours ago [-]
witx 6 hours ago [-]
What is the actual contribution and motivation of this post?
sensanaty 1 hours ago [-]
I don't blame him, if I had Anthropic's money hose pointed directly into my pocket I'd be spamming HN non-stop too
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.
softwaredoug 6 hours ago [-]
People shouldn’t overthink blog posts. Just write what’s on your mind and have fun.
rvz 5 hours 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.
> "only covering AI" - don't miss my wildlife photography!
The "ai" tagged posts (2,100+) significantly outnumber "sighting" posts by orders of magnitude. Even searching HN, this post is the very first mention of it.
Perhaps that is why everyone here (except you) overlooks that or why we don't see much more of those sightings posts here either.
simonw 2 hours ago [-]
Yeah, wildlife photography is a new hobby - it used to be every few months, now it's several times a week.
I would be very surprised if one of my sightings posts made it to Hacker News. Maybe if I manage to snap a photo of an actual pelican perched on a bicycle some time.
softwaredoug 5 hours ago [-]
There are many people with unbridled enthusiasm and an ability to write fast
Knowing Simon - he’s very much both :)
simonw 6 hours 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 6 hours ago [-]
At this point we all know the answer
6 hours ago [-]
throwatdem12311 2 hours 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.
aureate 7 hours 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 6 hours ago [-]
11k in two years vs 5k in two weeks? You're right, numbers speak for themself.
entrope 5 hours 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.
endospore 3 hours ago [-]
Their (public) project management is horrible, you can find fixed issues unclosed and unfixed issues closed. Not really surprising when that part of the work is completely taken over by LLM agents though.
preommr 3 hours 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.
6 hours ago [-]
7 hours ago [-]
zuzululu 46 minutes ago [-]
as it always should've been Rust was the right move
IshKebab 7 hours ago [-]
This post is just "they didn't lie"...
hmokiguess 2 hours 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.
baq 8 hours ago [-]
Turns out it was just a build step after all.
nottorp 6 hours ago [-]
So does that make Claude Code any better?
Can you select text with shift + arrow keys now in the command line client? :)
rs_rs_rs_rs_rs 7 hours 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...
jqbd 5 hours 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.
lazzlazzlazz 6 hours ago [-]
Seeing all the people up in arms that there was an automated rewrite of Bun to Rust has been very revealing and disappointing. Very silly behavior and denial over the inevitable.
ooofydoofy 7 hours ago [-]
bun upgrade --canary
you are welcome
7 hours ago [-]
thrance 7 hours 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.
kburman 7 hours 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.
esjeon 7 hours 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.
brabel 6 hours 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.
klibertp 4 hours ago [-]
Somebody checked[1], and they discovered that the "stages" past the first had minimal impact on the unsafe blocks count. That's just one metric, but it makes me doubt your claim that there was/is a lot of work put into making the translated code idiomatic Rust.
Isn't it just: "while true {refactorIdiomatically(); fixErrors()}"
folkrav 4 hours ago [-]
/goal fix all bugs
rho138 7 hours ago [-]
That sounds like a massive waste of finite energy and compute resources.
CrimsonRain 2 hours 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.
whateveracct 3 hours 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.
sdevonoes 7 hours ago [-]
We are the ones to get to decide. Do we want that? I don’t. But im just a single data point
hkclawrence 5 hours ago [-]
[dead]
marsven_422 2 hours ago [-]
[dead]
luciana1u 7 hours ago [-]
[dead]
marsven_422 7 hours ago [-]
[dead]
znpy 7 hours 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.
ifwinterco 7 hours 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 7 hours 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 4 hours 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....
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.
maverickaayush 7 hours 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.
roundabout-host 4 hours 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 2 hours ago [-]
the whole Ai skit is anthropomorphing the compiler as a coworker.
tappaseater 6 hours 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?
larodi 20 minutes 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.
delegate 2 hours 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 2 hours ago [-]
It was not really a traditional rewrite. More like transpilation. Still impressive
dgellow 2 hours 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
Rendered at 18:11:13 GMT+0000 (Coordinated Universal Time) with Vercel.
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/
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.
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.
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.
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).
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.
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.
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.
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".
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!"
Or those choices just don't matter, it's fundamentally just "tabs vs spaces".
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).
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.
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.
This is just blatantly ignoring all of the glaring issues Claude Code has had over its lifespan.
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.
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.
Edit, the sonnet question shouldn't be taken as proof, it knows I'm a rust dev.
the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.
I'm pretty sure "built to last" was only ever more true in specific contexts, and wasn't particularly more true than today.
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.
A ringing endorsement!
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.
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.
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.
My question is moreso “why was it ever JS in the first place”
& the cost of a native rewrite would be cheaper than acquiring Bun no matter how you shake it
I 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?
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.
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
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...
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.
That said, with respect what I clarified, I’m curious your thoughts.
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).
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”.
This is especially useful when you're trying to evaluate behaviors while changing state surgically.
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?
Is there a huge need to run that typechecking on browsers?
Secondly, WASM isn't the right target for the browser anyway, JS and the DOM have to be what you consider "native", for the most rigorous UI projects at least (which building an IDE is). If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.
It's not just typechecking, the typescript library is also the reference parser for TypeScript and reference emit. Emitting JS from TypeScript is non-trivial and non-local.
It's not just in browsers, you might want to run the typescript library on the edge or in some restricted environment where JS/WASM is OK but native code is not.
You may want to use the typescript library as a dependency in your own package. TypeScript becoming non-pure JS means that your library also becomes non-pure JS.
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?
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.
Maybe you're being coy by asking a rhetorical question you already know the answer to but I'll answer as if you asked sincerely...
There are 2 different groups interacting with software products:
(1) end-users : this is where the "Who cares what language it's written in?!?" is usually applicable. E.g. The finance guys using MS Excel don't care whether it's written in assembly, BASIC, or C Language.
(2) code contributors and/or programming language enthusiasts who see other projects as "validation" of the whatever language they've invested in: these people definitely care.
For all the decades that computer languages have been debated, Group (2) will always discuss projects language choices. E.g. reddit.com switching from Lisp to Python, the Linux kernel fiercely debating future Rust contributions , the Typescript compiler switching from Javascript to Go, Bun switching from Zig to Rust, etc.
People try to lecture others in Group 2 about "don't make a programming language your identity" ... but people are human and they can't look at all the above language choices as totally detached observers. They like to talk about it!
If one is a Zig coder that contributed to the previous Bun Zig codebase, we can't expect them to be neutral observers.
There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Group 3s in every similar convo, for any combination of technology, project, and acquirer you can name.
And for most part I don't think it was communicated well apart from the last blog post.
You just AI generated 1 millions lines of code claiming it's for safety. Who exactly is to make any kind of security guarantees about this?
With regards to AI-generated code, this means the copyrightability (at all, not with regard to who owns it) turns on whether or not a human was substantially involved in its creation.
Existing decisions require evidence of pretty heavy and continued human guidance to qualify.+
To wit, autonomous agent created code (prompt -> machine churns for hours -> output) is explicitly not eligible for copyright.
Functionally, this is a double-edged sword.
On the one hand, it means anything coded with autonomous agents by Meta, Google, et al. can be legally reused if it leaks (because no one could hold copyright on it).
On the other hand, it leaves copy-left open source licenses in a weird place. If you convert open source (even MIT/BSD-style) code into something else with an autonomous coding agent... the result has no copyright (nor can ever in the US).
In this instance, Bun was MIT-licensed, no? Then it was shoved mostly-autonomously through an LLM for the port.
Now Bun-Rust is technically still MIT licensed, but if push came to shove it seems like US law's current position is that Bun-Rust would now have no copyright license (because the manner in which it was developed renders it ineligible for copyright).
That's on the copyright side.
On the infringing usage side (i.e. whether you were entitled to shove a copyrighted work into a coding agent to produce something)... that's still TBD.
^ https://media.cadc.uscourts.gov/opinions/docs/2025/03/23-523...
+ https://garrettham.com/ai-generated-works-copyright/
Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues.
the language is relevant for political not technical reasons. you could say, blanket closing the Issues, getting rid of this thing called Jarred from your stack, etc., is really an attack on the GitHub and the GitHub Agitator Lifestyles, which is why so many commenters on Hacker News actually care.
This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it.
> poster child for Zig programming language actually being the prime example of How Not To Write Zig Code
https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
> 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?
And this is a valid question. You are not "defending reality" by refusing to listen to it.
In summary and based solely on my understanding:
- Jared misled people about the intentions of the migration. It's not the worst thing in the world, but it's certainly worthy of criticism.
- Jared has commented before about locking out human contributors from open source projects. Whether he was making a larger point is irrelevant as his comment stands on its own.
- Other Bun contributors, past and future, outside of those employed by Anthropic, did not and likely will not have equal access to the model Jared used for the rewrite.
Jared, working in the public Bun repository, used tooling not available to his community to experiment with a signficant migration. He dismissed all concerns and told people it's just a bit of fun, and that it shouldn't be taken seriously. Most of the controversy would have been avoided were the experiment done in private.
None of this is a big scandal but questions about the project are entirely justified.
Similar to the Claude Code 60s timeout incident [1] it could just be "Jarade decides what gets done and accepted"
[1]: https://news.ycombinator.com/item?id=48949942
Issues on GitHub was mass closed claiming zig is no longer relevant without fixing the real issues.
In fact a lot of "feature requests" like npm compatibility related or missing specs etc ALL also got closed for being "zig" because reproduction and suggested solution were of course zig.
Again doesn't mean it got "auto fixed".
* Open source because it ticks a checkbox but is only being really developed by a large team paid contributors and your changes (see: Chromium, most of Linux, Node, etc.)
* Open source because of belief that sharing it publicly will do good and collaboratively built by a very small group of core maintainers and others wanting to improve it.
Bun is now solidly into the third, absolute shit category: very small development team headed by a tech bro that shits out millions of lines of code he doesn't even know how they work and will inevitably collapse under its own weight while he swaps things out from under your feet.
It's not a language issue, it's a trustworthiness issue, and Bun was already pretty low in trust even before the Anthropic acquisition. In addition, we now have Claude Code running an unreleased version of Bun, for a while now: Bun is effectively not even open source anymore, just a source code dump from time to time.
> Inevitable collapse
According to who? You? The well ackshually guy?
> Low in trust before acquisition
Cite your sources.
> Unreleased version
v140 is the canary version which has been available for a long time.
https://github.com/oven-sh/bun/releases/tag/canary
> Not open source anymore
Who died and made you the dictator of open source?
Your post is just a bunch of opinions and lies and speculation wrapped as facts.
What is actually going on with that tag? It has files uploaded in Jul 29, 2024 and files uploaded "6 hours ago" (some hours after Simon first published his blog post). Do they not do proper releases with immutable tags and instead use one tag kind of like a git branch that mutates and changes over time?
I don't like that, personally. I think the project would be easier to reason about if they shipped alpha versions instead.
“bun the JavaScript runtime ” is not dead though.
I think even this is largely beside the point. The acquisition of any project by Big Capital (whether tech or VC) is usually a killing blow.
Can't help laughing at this point.
Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
In Zig, every single memory operation is unsafe.
And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors.
There's too much, sure, but can we at least be honest and reasonable?
I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good?
Was nobody here for moving billions of lines of JavaScript to Typescript? It starts with declarations, then turn on type checking gradually inside the codebase: piece by piece until done.
> must interface with C code that has no safe interface
Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2x as many unsafes.
And mind you if you haven't read the code, the vast majority of unsafe blocks in bun are for raw pointer access to local (Rust) objects because their ownership was a mess both before and after the rewrite. Also funnily enough a lot of the access patterns are wrong (in the Rust sense), leading to hundreds of new undefined behaviors.
> be honest and reasonable
Well, well. Talking about dishonest and unreasonable behavior, why is bun releasing a new version before solving any of those glaring issues? I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
Except, you know, multiple real companies saying that it is and using it in production. And the fact it closed all known memory leaks. And that nobody has a really pointed to a single actual issue the new version introduced after two months of endless, ceaseless bitching.
I'm also fascinated by all these people upset at Jarred for harming the readability of a codebase they've literally never cared about before it become drama. Bun has almost exclusively been maintained by Oven employees since it's inception.
> Deno for instance have ~0.2x as many unsafes.
A project written ground-up in Rust idiomatically, with a smaller surface area, still has an unsafe footprint within an order of magnitude compared to this automated rewrite from an unsafe language with different practices and known bugs? That's not exactly the slam you think it is.
I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language.
A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again.
> Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage.
https://x.com/typememetics/status/2078572052680790237
There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. Rust is so thoroughly and obviously the correct thing that using anything less correct should be taken as a sign of engineering incompetence.
This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of them, but “fine” as long as you take extreme care are not interesting to me. I’ve started calling this “simple as long as you avoid all the foot guns” idea the sword juggling fallacy[0].
It’s too bad about Zig because it has many nice ideas, in particular allocators, that I hope Rust or some future language will adopt.
0: https://hugotunius.se/2026/06/15/the-sword-juggling-fallacy....
AT&T was the one doing the Cyclone research.
And then we have a bunch of folks assuming they know better about C that its own authors?
However, people also report that the canary version doesn’t identify itself as version 1.4.
Doesn’t sound like responsible software deployment
> 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.
Which is still true as I write this comment.
What motive could he have for secretly maintaining a private fork of Bun that's shipped with Claude Code while simultaneously working on the open source repairs every day?
i am a clankersceptic as much as the next guy and i hate "anthropic" for participating in the murder of innocent people (maven "smart" system, offers them as a provider to the pedo criminal unitedstatistan government)
but this whole "unreleased" framing is just manufacturing drama / lack of knowledge
I don't see what it would buy Anthropic to have some sort of secret internal fork with special private code in it.
Now it is a Deno clone, both without anything enticing over node.js.
Stay your pitchforks.
I think it’s valid to object to. If 1.4 is good enough to be used by Claude, why not us?
That might even be the reason why they switched to rust.
Don't worry too much.
…but they have? Claude users are public, no? If they were dogfooding internally I’d agree with you.
You just can't win.
You could! You could not release a “pile of vibe coded slop” onto people’s machines. There don’t even appear to be any particular advantages to Claude upgrading early. If there are no one has been made aware of it.
I believe you've just made your opponent's point for them.
But more to your point: Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
> Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
Hell yes, and anyone who trusts one of the AI labs for anything important is insane.
Whether it's their initial mass piracy and then lying about it, dealmaking with the US government, or continually shifting opt-out lines on what they are and aren't training on, they haven't earned the trust to skip the "but verify" step.
Their economic incentives are too transparently aligned with ends at any costs.
At this point, charging is the least of your issues.
It's true that we don't know exactly which, and whether or not there are any other changes added on, but that is the case for every single release of Claude Code that has used bun.
from strings:
This build does have a different way of identifying itself than earlier builds so it's possible this string isn't correct.(In contrast, earlier builds that I have locally have commit IDs that can be found in the public repo). I don't think it's particularly damning for them to vendor a canary release, mind you.
> 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
There’s no implication that it’s because of the switch to Rust.
I was responding to your GP comment. For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
What?
Now, /you/ are trying to move the goalposts into an entirely different argument.
Very likely it’s just anti Anthropic altogether.
Like I said, a meme.
Anthropic hasn’t done anything wrong but if they move a single inch then people will complain. Perhaps it is just a preview version?
I’m sorry but this is a nonsensical debate.
> Now, /you/ are trying to move the goalposts into an entirely different argument.
You said something and I responded to it. That’s invalid too now? There can only ever be one single objection in a conversation? I’m not permitted to react to the things said? Like I said, nonsense.
I'm just one person though, and have no problem with a move to language X, using tool Y, who cares?
For "goalpost are being moved" to be valid here, you have to be able to point to someone saying one thing at one point, then same person putting a different target later. You're folding a huge group of people into one person, when that's not really accurate to do.
https://news.ycombinator.com/item?id=48837877
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).
In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun.
In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
It's not about making the dev experience better than node, that use-case is now secondary.
Theres thousands of PRs from claude agents or whatever.
Yeah really feels like a worthwhile place to contribute lol.
FOSS as in FOSS - Free and Open Source Software. Has nothing to do with if it's community driven or not, I'm strictly talking about FOSS.
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.
The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed hard work from hundreds of community members.
All those PRs can be fed thru Claude and converted to rust and then manual polish can be added.
Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.
It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
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.
Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime!
The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
Everything is in the open: PR #30412
Ok, go ask those people what they think then, I feel no outrage over a project switching language or merging whatever. But when once-semi-transparent projects become more opaque after an acquisition, I'm starting to readjust anything to the project I had in mind.
If you can't find an update at that place in the codebase saying 1.4.0 you can ask where it is. It seems after doing that and not receiving an answer would be the appropriate time to start making the claims that people are throwing around.
This seems like a candidate
https://github.com/oven-sh/bun/commit/b18bf6d1d0a92238f240bf...
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.
~$ bun upgrade [2.42s] Upgraded.
Welcome to Bun's latest canary build!
Report any bugs:
Changelog:Version was changed in Bun in May 18
https://github.com/oven-sh/bun/commit/b18bf6d1d0a92238f240bf...
So it has been canary since then, most likely, if docs are accurate that latest main is canary.
Nevertheless, the principles of open source never demanded more than providing the source upon request.
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
Where? Is see no CHANGELOG in the root. I do see LATEST, last modified 2 months ago, and it says 1.3.14
> Upgraded the bundled Bun runtime to 1.4
(Though that doesn't clarify that this is the Rust rewrite)
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?
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.
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
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
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!
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.
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.
If nothing prints "Segmentation fault", this just sounds like a hang
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.
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)
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.
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.
This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.
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.
Given the success of the port so far and the fact that CC is now running on rust Bun, that seems highly unlikely to me.
I'd also like to inform you that
- the current success metrics solely consist of their advertisement, my eyes looking at the code strongly suggest otherwise
- the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust and relying on model knowledge is already proven insufficient.
The release decision itself is presumably driven by that tbh. It's only LGTM from there when nobody knows how to review unsafe Rust.
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.
Is all you need to know to consider how much of an abomination it is
ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...
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?
True.
> has fewer bugs
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)
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.
Anthropic seems to be all in on 100% AI code.
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 :)
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
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.
If anyone else did that on HN, they would be accused of slop with their domain blacklisted.
(Unless photos of actual pelicans count as "AI" content now.)
I just shipped this filter UI so you can see my other non-AI-tagged content in one place: https://simonwillison.net/search/?exclude.tag=ai
The "ai" tagged posts (2,100+) significantly outnumber "sighting" posts by orders of magnitude. Even searching HN, this post is the very first mention of it.
Perhaps that is why everyone here (except you) overlooks that or why we don't see much more of those sightings posts here either.
I would be very surprised if one of my sightings posts made it to Hacker News. Maybe if I manage to snap a photo of an actual pelican perched on a bicycle some time.
Knowing Simon - he’s very much both :)
(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.)
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.
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.
Can you select text with shift + arrow keys now in the command line client? :)
you are welcome
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.
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.
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.
[1] https://news.ycombinator.com/item?id=48967630
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.
> 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.
Just that?
I was expecting more from that rewrite. Maybe Rust is not so worth it after all.
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
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.
You wouldn't notice either of those if you were a user, unless you happened to hit one of those bugs.
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?
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.
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.
…if you have the compute and capital to run that whole agentic system