Claude Code uses Bun written in Rust now(simonwillison.net) |
Claude Code uses Bun written in Rust now(simonwillison.net) |
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
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?
Can you select text with shift + arrow keys now in the command line client? :)
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.
And the crowd is cheering.
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.
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.
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.
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.
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.
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.
It's like "why did you go all in on buying scamcoin 3.0 as your investment strategy?" -- "I 5xed my money! End of story! It was fine!"
The engineer is suggesting that it could be done cheaper and maybe with better outcome. Ironically, this is a classic business case.
You can make anything work when you have enough money to buy and radically change the entire runtime you’re relying on.
One must suspect that if they did not have insane amounts of money to burn, they could have tried other approaches to fixing the problems. Maybe engineering, perhaps.
A ringing endorsement!
I'd argue these tech companies got popular because they have good models, nothing else.
Even OpenAI took two years to fix basic chat scrolling.
The point is that if you were starting a new TUI LLM harness today, you would basically use CC's architectural decisions as a guide for what not to do.
But the "coding is mostly solved" narrative kinda doesn't match right? If good, correct, high-performance software is like, free now? Wouldn't you want it to be slick as hell, really reliable, all that? Even a little breakage costs a lot of money at that scale and pricing, it would be better than a wash if you put the magic code thing on the case.
"Claude. Do all employee work. Make no mistake. Notify in slack when revenue is double."
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.
I suspect user facing/fast moving code (UX layer) will move to dynamic systems with fast iteration times. Infra layer will move towards safe systems level environments like Rust. I'm not sure where Java/C# lands in all of this - it's kind of the middle ground between these two worlds but the tradeoffs change drastically with LLMs - my gut feeling says that TS/Python is good enough for UX work and Rust is better for systems work so it gets less popular going forward.
[1] https://avi.press/posts/2026-07-10-after-7-years-in-producti...
Also GHC has an interpreter. It powers the REPL. No need to compile everything if you’re just experimenting. I do find that in the Haskell world the REPL is criminally underused compared to Python.
And the rest of your comment doesn’t make sense; this shop is rewriting their infra (not UI) from Haskell to Python.
I've read and heard in videos that Javascript is a pretty good language for AI to write code in. Apparently this is because there is so much training data out there. Also Javascript avoids problems of multi threading and memory management that can mess up the AI in other "more performant" languages.
So maybe Javascript is not the worst choice for writing software fast with AI
The latest frontier models are competent at Rust and Swift and all manner of other less widely used languages.
The more important factor is how good they language's compiler is at kicking out actionable error messages, since one-shot code generation isn't as important once you have a coding agent loop.
Proves LLMs don’t help with taste.
Yeah, good question. OpenAI decided to rewrite Codex in Rust about a year ago[0].
In fact, since rewrites are that easy, what do we need Bun for? Why doesn't everybody just port all of their Javascript code into Rust?
Is this because Codex is written in Rust and not JS? I dunno. I think it's more just "lighter" in general, or it certainly feels that way. It's probably possible to make something with a similar feel in JS, just perhaps not with the big honking mess they've created.
Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.
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
This is close to the same "why Spotify is a chromium embed?" question. Because it works, and users are ok with it.
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).
It's hell to maintain for not much gain (for a use case like this at least). As much as it's become a meme, JS and web tech in general has become extremely portable and stable.
I also don't think Anthropic bought bun to make their TUI better. They could have forked it, they bought bun because it incidentally was excellent for the way agents prefer to work and they wanted to capture that audience.
Their new flagship product (earning them billions of dollars in revenue per month) was dependent on a platform maintained by a tiny startup.
Buying Bun was a very rational way to reduce that risk, epically since it also got them some top tier engineering talent.
Thinking about that further, I wonder if that was part of the rationale for switching from Zig to Rust that they haven't talked about?
Zig is a much riskier bet for your multi-billion dollar cash cow than Rust is.
But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.
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/
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?
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?
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?
Claude Code isn't the only user of Bun (it's probably not even the only user of it internally at Anthropic), and this way they get to keep the Javascript runtime (and other tooling) that their coding models may one day, if not already, prefer to use when given the opportunity. For those kind of apps, you'll probably also eventually find that--what do you know!--Anthropic also has their own cloud offering (instead of Bun being the one to build one) that specializes in running and managing those applications for you. Even if all they get is a community of developers that choose to use Bun over other options, that gives them power and seats at tables they wouldn't have if they just rewrote Claude Code in Rust.
That'd be my best guess, anyhow.
I think a JS runtime is fine because the ecosystem of tools is very large and plugins are easy.
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.
A dirty secret of AI data centers are that they’re only getting 40-60% efficiency out of their GPU clusters and because the moneygun go brrrrr they just buy more.
You wonder why they’re so afraid of the Chinese competition… they can’t afford to be as wasteful
> Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript”
> The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO.
> If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It turns out, there's some similar sentiments in the last year ish:
https://news.ycombinator.com/item?id=47043325
https://news.ycombinator.com/item?id=47105720
https://news.ycombinator.com/item?id=48001113
https://news.ycombinator.com/item?id=46134570
https://news.ycombinator.com/item?id=46124596
I'm not a fan of any of the technologies, companies, or people related to this. I just couldn't shake the feeling that I've seen similar comments.
September and all.
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.
(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.)
AI is pretty good at rewrites and ports. Quite good infact.
I have a long running side project I migrated to bun, and I'm starting to regret it. I don't want to build on top of this much churn.
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.
It's like asking "why does everything run on Windows?" Because everything runs on Windows.
No, you are not crazy. They do crazy things with unlimited budget, and still their chat app flickers when using.
They should just port pi-tui from pi coding agent, since they have no clue.
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.
You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (like what llms generally prefer), it doesn't make sense to use it.
I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd.
That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with this). Instead of using a language with builtin guarantees & optimizations around handling this so your object pools don't need to carry around a bunch of function pointers. C++ has aggressive de-virtualization passes so at runtime a lot of the 'complex object hierarchies' can be flattened to purely static function calls.
A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.
Even with the huge amount of "unsafe" rust currently in bun? https://news.ycombinator.com/item?id=48967630
Of course they’ll iterate and remove the unsafe bits which were necessary for the transition
All of this is just a (succesful) marketing stunt by Anthropic.
"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."
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.
“bun the JavaScript runtime ” is not dead though.
It's not about making the dev experience better than node, that use-case is now secondary.
Now it is a Deno clone, both without anything enticing over node.js.
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).
Theres thousands of PRs from claude agents or whatever.
Yeah really feels like a worthwhile place to contribute lol.
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.
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.
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.
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
In Chrome or Firefox, a segfault is usually automatic CVE and in most cases a bounty of thousands of dollars…
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.
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.
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
2026-05-14 23427db 13907
2026-05-14 19d8ade 13861
2026-05-15 4d443e5 13840
2026-05-17 172afa5 13803
2026-05-17 80a06a8 13849
2026-05-18 fba43af 14026
2026-05-19 303cd28 14052
2026-05-20 21db682 14243
2026-05-22 a06a00a 14239
2026-05-23 49c97de 14090
2026-05-28 472a06a 14076
2026-06-01 a0d1472 14071
2026-06-04 8553428 14032
2026-06-09 717542f 14053
2026-06-10 1c90e5a 14043
2026-06-11 6e91d24 14031
2026-06-16 bd8edc7 14086
2026-06-17 6ef5977 14104
2026-06-20 315ed50 14106
2026-06-22 c6be834 14120
2026-06-23 ea7e44f 14108
2026-06-23 03042ab 14128
2026-06-29 86d32c8 14046
2026-07-01 6640fcf 14077
2026-07-04 51074e3 14099
2026-07-06 9d0e93d 14186
2026-07-08 ab6eb2d 13953
2026-07-09 86caf6e 13936
2026-07-10 91675d0 13930
2026-07-13 73b6c14 13951
2026-07-16 4bbe075 13978
2026-07-16 57e30a5 13995
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?
I just thought it was interesting. I'm a fan of TUIs, both positive and negative about JavaScript (the modern language is quite nice, given you avoid the historical warts, in my opinion - the ecosystem is unfortunate), and I think the best description for how I feel about LLMs is that I'm bearish. Also Simon is a fantastically prolific and intelligent person though, even though LLMs are not my cup of tea.
https://news.ycombinator.com/item?id=48960912 is a recent comment by someone I also respect related to how LLMs recreate human-like content (Widgets, really), making actual human-created content feel fake.
Sometimes it sure does feel like ELIZA is the main news source these days.
As it is now, your post is meaningless to me.
Oh, that's buggy too. I just tried Claude Code on win10 powershell, and the first typed character goes in the wrong spot and can't be backspaced.
It is by far the the least reliable program on my machine, and every time I have to interact with it I feel like walking in eggshells.
If you have unlimited access to the magical development tool, then why would you not?
But they haven't.
Like Ada or Ocaml or Haskell or something.
Or even require like MC / DC testing or MISRA C verification.
Or even some of the languages that apply Hoare checks, like Ada SPARK or FRAMA-C or VALE or whatever.
I don't have the budget to test how that would work but it seems interesting.
To me it comes back to the premise I hear a lot from AI hype men (of which I do not subscribe but it’s worth clarifying that I find great value in using it for code) that the code doesn’t matter anymore. I just don’t know how to square that claim with the idea that we’re limited still by JS/TS being easier to use or approachable despite inferior TUI toolsets.
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.
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.
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.
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.
Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.
To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?
1. You're writing code you don't have to
2. That adds runtime overhead
3. That when you screw up has non-trivial security & resource management side effects
This is objectively indefeasible in nearly any vaguely professional context.
2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.
3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?
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.
And I can believe you because I’ve seen JavaScript-heavy Safari tabs crash.
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.
> Upgraded the bundled Bun runtime to 1.4
(Though that doesn't clarify that this is the Rust rewrite)
But look at your own disclosure page [0]: OpenAI paid you for your time at a GPT-5 preview, and you regularly get early access, embargoed previews, and free API credits from OpenAI, Anthropic, Gemini, and Mistral. So "I've made no money from Anthropic" is narrower than it sounds, access and preferential treatment are compensation too, even if cash didn't directly change hands.
Same goes for the sponsor list. Microsoft is OpenAI's investor and infrastructure (or was anyways, I've got no clue what the status of that is these days), Amazon and Google are both major Anthropic investors, and most of that list runs on Azure, AWS, or GCP, or sells tools built on these labs' models. Taking a Microsoft sponsorship isn't really separate from an OpenAI one, it's just a single hop removed. The entire software ecosystem and all the players in it are entangled in this bubble.
I'm not accusing you of consciously hyping any of them. Your posts are high quality even when I disagree with the contents of them. You often list downsides too, prompt injection, security, slop issues but the throughline still repeats: this is inevitable, get on board. Product-market fit found, November 2025 as the inflection point. That kinda framing shows up again and again throughout all your posts.
It's refreshing that you're upfront about the previews and credits and all that jazz, but surely you understand why some people stay skeptical even with that disclosed as it confirms the access exists.
Whether you realize it or not, I think they are indeed paying you in some sense, which is part of why I'm skeptical when your posts consistently land at the top of HN. Not because the writing isn't good, but because I think the same incentive shaping the coverage probably shapes some of that reach too.
[0] https://simonwillison.net/about/#disclosures:~:text=2024%2E-...
Nobody is unbiased, no matter how hard they might try. I like to get my information from sources where I understand their motivations, so my approach is to try to make my motivations as clear as possible.
(That's why I spend an unreasonable amount of energy arguing with people on Hacker News who call me a shill!)
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!)
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.
I'm not quite as optimistic. "Unpleasantness" might sound like subjective disgust, but it often relates to objective criteria like complexity, that increases the surface area open to bugs in a real way. Similarly, if reworking has a non-0 chance of bugs, its gonna have some form of risk, and a major one will of course be higher.
LLMs may be capable of a lot, and they miggt change what projects people can take on, but they definitely don't write bug free code.
The bun rewrite/transpile did use some neat ideas like lots of testing and per-file translations, so hopefully they have more in their toolbox than "LLMs hopefully won't be affected by complexity or write bugs"
> 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?
> One probable outcome of an unsafe-language-dominant world is full Andrew communism, which is precisely what Andrew “Smelley” Kelley proposes: abolish ICE and replace the market economy with a globally distributed network of community-maintained allocators.
> Rather than a commercial product, software becomes a “public good,” ultimately provided by the Zig Software Foundation as manually managed digital infrastructure.
Calling him "smelley"? Really? Pulling in the political views of the founder of a language and claiming that they inform his language design as part of a grand conspiracy against Rust/capitalism? Where are they getting all of this? Free, open-source compilers and related tooling (both of which Rust and Zig have) are already public goods managed by global communities of mostly volunteers
> This future strikes me as a dystopian hellscape, but I have never met an unsafe-language advocate who could explain how this ecosystem is supposed to sustain itself without unpaid maintainers, ideological volunteers, subsidized infrastructure, and endless donations to compiler projects that still cannot protect users from basic memory errors.
How is Rust any different than Zig in this respect? Both are projects largely run by nonprofits relying on communities to promote, maintain, and improve them.
Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues.
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).
Or many billions. eg. Facebook was originally written in PHP.
As a 52 y/o who cares deeply about software development as an art I don't have trouble admitting that the tech hardly matters relative to the economics, that was obvious to me very early in my career.
I have just never really cared because there has always been a path where you can have a decent career being paid to work on and with good technology in spite of the fact that the technology wasn't important to the economics.
I do fear that the rapid adoption of LLMs will probably cause the path I took to narrow considerably. There will likely be less companies willing to pay people to work on elegant technology when they are all competing against endless code generation machines (and this is assuming software companies can exist at all in this future). But at my age that's more of a concern for younger people than me.
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.
Tabs vs spaces makes no tradeoffs. Tech choices do
They couldn't even fix flickering in their TUI and their new renderer is complete garbage.
They succeeded despite their tech.
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.
Most people would choose to swim a lap through a pool of pee to get a billion dollars at the end. The pool of pee itself wasn't the once in a lifetime opportunity (for most).
Sorry, I'm bad at analogies.
This is just blatantly ignoring all of the glaring issues Claude Code has had over its lifespan.
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.
You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.
Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.
(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 :)
However, people also report that the canary version doesn’t identify itself as version 1.4.
Doesn’t sound like responsible software deployment
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.
> they need a high powered game engine rendering loop
Don't believe the bs on twitter. Claude code source was leaked, there is no high powered game engine rendering loop.
> It needs to stream text to stdout
These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. If the work was split across threads they would not use anywhere close to as much power and there would not be a slow ui.
If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.
The reason the computer gets hot and uses more power is because the cpu is getting close to 100% utilization.
> These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown.
The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want them and would appreciate a way to disable all of that to reduce CPU use.
Casey Muratori addressed this years ago with the windows terminal drama, https://github.com/cmuratori/refterm
Bad coding is just bad coding.
It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
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.
Do you know how silly this sounds? Good engineers can work in any language. At the top companies (of which Anthropic is certainly one) they don’t have “C++ engineers” and “rust engineers” they just have engineers.
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.
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?
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:
bun-v1.4.0
f6d0fcd24abd48061873c2f1a6fb2a67eee487b8
Upgraded.
Welcome to Bun's latest canary build!
(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.
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.
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.
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.
Barthes aside, C's changed a lot in the years since they left.
Still they are the authors, and withdrawing from WG14, going their own direction with Alef, Limbo, and finally Go, kind of proves the point they considered C done for its original purpose.
They were up and running and super-productive with Django within a week.
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...
> 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.
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.
~$ bun upgrade [2.42s] Upgraded.
Welcome to Bun's latest canary build!
Report any bugs:
https://github.com/oven-sh/bun/issues
https://github.com/oven-sh/bun/compare/f161e0311...98f664962Nevertheless, the principles of open source never demanded more than providing the source upon request.
Put up the code and prove it. We already know exactly how fast golang is in comparison to nodejs on basic numeric computations, it's roughly 40 to 50% faster.
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.
A lot of people go “js is bad” reflexively and they are right for the wrong reasons. Its not because js (specifically v8) is slow. I have many websites and web based apps open and none fuck up my laptop as hard as claude code.
The UI itself requires laughably simple tech. The idea that a markdown renderer that can produce HTML at 50MB/s would use much CPU to process incoming hundreds of bytes per second is insane. CPU should be idle even if doing that constantly. Nevermind that between turns it has nothing to do whatsoever and should use zero CPU at all.
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.
You might get more maintainable code for $168k by hiring humans, but if its something bespoke it isn't going to get you far (or far quickly).
Vibing is straight out gambling right now, the thing is, I don't know who the house is any more.
For an entity like Anthropic that's not even the cost of a single developer for a year. It's closer to what they pay a chef on premises.
That the showstopper for a better Claude agent is that they'd need to pay $168k or event $1M or even $10M in costs, can't be used as an excuse.
Does anybody really believe that it only took 11 days, one engineer and $168k in tokens?
Jarred used many agents and they worked 24/7. It tracks for me.
So yes, I do believe it. What makes you skeptical?
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.
Why would it be harder and/or more time consuming rather than the opposite? It's like having full specs and a full test-suite to match against the result you want.
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".
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 can be true, while "nullifies such "business" concerns" can be false. Both are not dependent on each other.
Automation doesn't "nullify business concerns", it just changes them.
Eventually? I am sure they would agree. Currently it's you (and lots of people like you) who are doing the supposing, not Anthropic.
That said, with respect what I clarified, I’m curious your thoughts.
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.
The argument I responded to argued that cost might be the prohibiting factor. I'm saying that for them, the costs mentioned are negligible.
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.
Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code).
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.
Known unsound code should not be merged, let alone released to production. If you have good enough tests and run them under MIRI or ASAN, maybe you can get away with it for a time, but most Rust experts would not sign-off on such a project.
If somebody put a gun to my head and told me to make the best of such a codebase, I would try to figure out how to turn off the LLVM optimizations that assume the Rust references don't alias. With these optimizations this codebase is scarier than most C or C++ code.
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.
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?
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.
You'll need a citation for that. While I'm still not sure whether Claude Code's issue tracker is worth much (Anthropic doesn't seem to engage with individual issues a while lot), it still has 5k+ open issues ranging back to March 2025. Bun also still has all of its Zig-timeline issues, all 5k+ of them. So what's this about?
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...
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".
I don't consider the following comment to be good, honest, and open communication:
> 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"
It seems like when some folks see “open source” they think the project maintainers owe them something.
An open source MIT license of the source code is very different from being the original copyright holder.
What?
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.
> There’s a very high chance all this code gets thrown out completely.
... and a few days later he decided that the code wouldn't get thrown out. That doesn't make the comment itself dishonest, he didn't have a crystal ball.
You can absolutely argue that the rewrite was not communicated clearly once they committed to it, but I don't think the comment you linked to there stands as evidence of poor communication at the time it was written.
And for most part I don't think it was communicated well apart from the last blog post.
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.
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...
I think it's the "infringing usage" question that is more interesting. If the LLM trained on GPL-derived code, what does that mean for the end result?
Either it means nothing at all, or it means that a substantial portion of the code produced at some of the world's most valuable companies over the last two and a half years is GPL.
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.