Author here: An apology on the graphs, they just count rust files touched in commits, not total commits. So if there were two commits and one touched 3 .rs files and another touched 2, it'd be counted as 5 for the purposes of the graphs. I may fix this later but, yeah.
I did suspect that the triumphalist pronouncements, and even the seemingly honest and forthright deep dive, were a little premature.
This is a key problem with LLM exuberance: it's very tempting to trade on decades of experience in software using LLMs, because one is tired of typing and manual figuring-out, it seems to work if you're competent, and the payoff is essentially immediate. The real bill comes in the mail much later.
I consider typing to be secondary to software engineering, but I do concede that for those cases that typing really is the bottleneck, LLMs can certainly be of value.
Oh, I 100% agree. I'm imagining the case where someone asks an LLM to do trivial things just for the novelty, or because they are fatigued of thinking + typing, but conceptualise the thing they are putting off as primarily a problem of typign and not thinking (I often do that).
This is so real now that we have LLMs. The stuff I'm working on doesn't seem to exist in LLM training sets, but I still get tempted to try when I get tired of doing the tedious parts.
Many repeat the point of “$165k is cheaper than team of multiple engineers working on the rewrite for a year”, which I think is flawed — the team of engineers would have produced idiomatic rust, and it would take probably 100k+ of tokens more to make the bun in rust idiomatic rust.
Also worth noting simple horizontal centering of divs was never a problem, margin: auto was defined in CSS Level 1 in 1996 [1].
It was vertical centering that took a very long time to crack, which really became trivial with Flexbox which was first drafted in 2009[2] but became available unprefixed in browsers between 2012 and 2014 [3] about 13 years ago.
Presumably lots of stuff wrapped in 'unsafe'. I'm not a rust guy or a rust fan, and the last time I wrote something with Rust was like 7 years ago, but to my memory, because of how Rust manages mutability there are many access patterns that are Rust-specific; idiomatic Rust is going to use this patterns but they would be unlikely to show up in a language with a different type system / borrow checker / etc. etc.
It's mostly the same in any general purpose programming language though, parts of the language features are meant (or became seens as) tools to be used in very narrow cases, which people less familiar with the language tend to "overuse".
Eg. goto/jump, bare "except" statements in python, etc... In Rust, unsafe has its uses and is a first class language feature, but it certainly isn't idiomatic to use it to mimic access patterns from other languages (unless absolutely necessary).
The Bun author himself writes that the port is not idiomatic Rust:
Do the rewrite that looks like we transpiled our Zig code to Rust. We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.
The original version of Bun was already a line-by-line (manual) port of esbuild from Go to Zig (also mentioned in this post), so the Zig code already wasn't "Zig-idiomatic" and apparently riddled with problems. That doesn't inspire much confidence in the LLM-translated Rust version tbh.
It means "don't misuse parts of the language in ways that circumvent best practices" one of which is "keep unsafe regions as small and few as possible" not "never use unsafe"
Meh. The (a major?) goal of Rust is this sort of type safety flowing down to memory bugs. Not every possible access pattern was known at the beginning, and generally they developed a philosophy of keeping the "unsafe" memory access patterns extremely bounded and heavily inspected. I think that's a fair and admirable goal.
Rust contains the ability to do everything that C can, if you use `unsafe`. And a file-by-file rewrite in Rust from another language usually involves keeping the ABI and API between files very C-like (and unsafe). In practice this means that the result of a first pass this way has all the memory safety of C code, but with worse readability because Rust makes unsafe things less ergonomic.
To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.
I don't think this latter stage has actually happened with Bun's codebase. The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).
one that an unsupervised LLM rewrite is probably not even going to attempt.
Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).
An LLM definitely can do that work, but LLMs have a tendency to follow the path of least resistance unless you force them to do things properly and carefully supervise them.
LLMs have a tendency to follow the path of least resistance
That's a really strong motivation for the Rust port. It's literally impossible to take a path not leading to an unacceptable outcome because the Rust compiler fails the compile if code no longer marked "unsafe" is still actually unsafe, and the tests fail if the implementation is incorrect. The compiler actively helps to force the LLM to do things properly.
…only if you actually force the LLM not to use `unsafe` somehow! And one must remember that `unsafe` can have all sorts of non-local effects. One way to be maliciously compliant (or in the LLM's case, I guess it's more incompetence than malice) is to make a “safe” function that does an `unsafe` operation for you, and then replace every usage of that unsafe operation with your “safe” function. You can remove hundreds of unsafe blocks that way without any improvement in safety.
Yeah this is going out of scope now. The in-scope safe/unsafe is that which is specifically recognized by the Rust compiler (literal greppable keyword). With that and the tests weighing I'd say it's pretty difficult to be incompetent, as the correct path becomes the easy path. Even if the LLM were to somehow go the maliciously compliant route I'm thinking it'd burn so many beyond-expected tokens trying to get around both compiler and tests that it'd be caught.
To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.
You can use deterministic linting for `unsafe` usage, have agents target `unsafe`, etc. It's pretty easy. You can even run `miri` against the code and give that as a tool for LLM feedback. I've done this all before and it works fine.
The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).
I'm unconvinced that this is true. How could you tell? You only know about the rust bugs because rust makes them grep'able/ trivial to verify, there's no way of knowing which bugs existed in zig that didn't translate. Regardless, the problem is now trivial to understand in Rust and start to target.
This is assuming your engineers don't leave for higher-paying roles elsewhere. The market might be cold generally but for engineers working at these frontier AI companies it's red-hot.
And most executives are figuring this into their calculus right now because they were burned badly during COVID. Meta, Google, etc were loose with hiring and engineers flocked from their lower-paying companies in droves. The brain drain was real.
One public company I was at lost nearly 2/3rds of their engineers and mostly to Meta (granted, they had other problems but it was mostly about money -- the offers were excessive). Then market conditions forced them to freeze hiring and they've had a slow exodus of senior talent since as the firefighting has become constant.
AI adoption has only accelerated problems for them.
We've taken this "only two years and then leave" philosophy to an extreme and now companies are totally justified in not investing in their engineers anymore.
The job-hopping followed from companies not investing in their engineers, not the other way around. It was billed as the only way to get a promotion (which usually would come every 1-2 years).
I've been in this industry for a few decades at this point and I was around when this meme was started.
It was purely about maxing your compensation because changing jobs nets you more than promotions & raises.
I've never met an engineer in my life who truly earned a promotion every year and very few every two. Very few companies have org charts that even support that or have that many levels. This logic/advice only really applies at a few companies and people have adopted it no matter where they work. There's not enough growth/hiring at 95% of companies to even come close. The Peter Principle is also a real thing. Everyone's competence has a ceiling.
There's even an implicit understanding of this that people at smaller companies have inflated titles and you typically rank them down 1-2 levels when hiring/acquiring at larger companies.
Now I do agree that companies haven't been investing in their engineers, but that doesn't also mean this isn't a vicious cycle. Employers and employees are in a mexican standoff and things are only going to get worse until one side comes to its senses. Employers have all the leverage for it to not be them.
For the vast majority of companies the average tenure of an engineer sits between 18 and 30 months. They're also mostly hiring young engineers in their 20s. As an employer what is your upside to making such investments before they're at least mid-career? A lot of people seem to want the world and offer nothing in return for it.
It was purely about maxing your compensation because changing jobs nets you more than promotions & raises.
You don't view it as a problem that companies consistently compensate new hires higher than they are their experienced employees?
Hell, I would have been perfectly happy to never change employers in my entire career to date, if my salary had anywhere near kept pace with my peers who were job-hopping.
You don't view it as a problem that companies consistently compensate new hires higher than they are their experienced employees?
It depends on the current employee and the incoming employee. They are not interchangeable cogs. Also not everyone consistently provides good value over their tenure -- a lot tend to work hard early and then for various reasons taper off. It's not necessarily their fault, but companies definitely are aware of this.
Personally I tend to value growth of my skillset over growth of income and that has largely informed my movement. I move when there's no longer interesting work if the compensation is at least fair. I've never been about comparing myself to others -- especially when most of my peers' left the industry after 5-10 years.
a lot tend to work hard early and then for various reasons taper off
And you don’t think that has anything to do with incentives (or lack thereof)?
I've never been about comparing myself to others
Doesn’t have to be about comparing oneself to others. More about the cost of living increasing because software engineering salaries are rising around you…
I currently work at a company where the average tenure is somewhere around 7 years. Wanna know their crazy secret? They don't treat their employees like disposable cattle, and actually invest in them! Our salaries go up yearly a few % above inflation as the bare minimum, we have great benefits, there's no crunch or overworking culture etc. It's a company with ~5000 employees globally too, not a tiny startup burning cash.
I'm similar to many people, I wouldn't have left some jobs in the past had I been treated with a modicum of respect and if my compensation went up with my tenure. But time and time again, pay ranges go up as new hires join in, but you're treated like you're insane for asking your compensation as a senior to match the compensation of a newly joined junior.
Would they have, in a year? The general plan of attack would likely still be the same: rewrite it in rust while keeping the structure as similar as possible, no matter how unidiomatic, then adjusting the design to make it more idiomatic to rust. Doing both at once is much harder.
I think with sequential approach (translate -> make idiomatic) it is easier. However, I am not sure that monetary difference is going to be as stark as $165k vs 3 engineers/year. Especially, if you consider that no one knows that is what in the code at the end.
Sure, you can argue that now it doesn’t matter — agents and all that, but I am not so sure.
Yes this is a typical case of showing results fast. I wonder what the cost for the remaining 10℅ of debugging and fixing all the bloat will be. Not so cheap I am guessing
IMO a team of engineers (presuming this is pre-AI) would have improved the existing Zig codebase, rather than spent time and money on a Rust port in the first place. In fact, I still think most teams of engineers would choose to improve what they have even now, circa AI.
Yes, and curiously many of the tellings of this story don't account for the costs of the human software engineers (Jarred and the other bun team members) who guided all of this work.
This post doesn’t make sense. It was rewritten in Rust. The rewrite itself is complete (no more Zig).
Various people have claimed that Bun in Zig had a lot of tech debt. If they’re to be believed, it seems natural to assume the rewrite does, too. Perhaps all this activity is paying down some of that debt.
I do not really care, just pointing where people's assumptions might be coming from.
The beauty of FOSS tho is Jarred owes the community nothing, and anyone can fork bun previous to migration and keep maintaining it on zig if they so wish.
bun in zig was used by many companies. some were using it in prod. how many of those are using it in prod? none, because bun in rust is not released yet.
Hence, the author concludes that rust rewrite is not complete as bun in rust is not released yet.
The rust version is being used by Claude Code though - which is a fairly large product!
I was hoping for more push back against https://bun.com/blog/bun-in-rust - which is pretty thorough and has some decent arguments and reasoning for why they did the rewrite.
it doesn't imply that lot legacy apps won't crash in prod when it will be actually released. Cool that some complex app is working but is nothing proving that everything will be fine when everyone will try to upgrade.
Author kept "going" in title because there has been no minor/major release in last two months which unusual for this project if you review the older releases.
A major rewrite in another language is also unusual for this project.
It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0. That work was done in parallel; here the work is being done serially — and it’s likely to take much less than a year for a new release.
It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0.
These are not comparable at all. The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem.
TypeScript 7.0. by comparison is not just a translation from one language to another. It's a true rewrite that at the same time has to consider a massive existing ecosystem (which needs to catch up first or you risk fragmenting it). Plus you might as well consider 6.x part of the effort, since that was the stepping-stone.
Also where bun really is just a runtime implemented with a bunch of glue code plus supporting tooling, TypeScript is much more complex. Change one part of TypeScript and you can get cascading issues somewhere else in the compiler easily. Change something in Bun and you'll likely just break some discrete part.
The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem.
This seems self-contradictory. If it's just a translation, doesn't that mean it remains fully compatible with that wider ecosystem? All the existing APIs retain identical behavior given the preexisting comprehensive test suite that had to go 100% green after all.
Passing an existing test suite just moves the optimistic lower bound to incidental compatibility, it doesn't move it to intentional - "regard" implies you gave it thought.
Plus, it's not just about code: it's also about giving the ecosystem a migration path. Dumping 500k LOC on people and discontinuing development of the zig version effective immediately (there hasn't been a release since and the zig tree is only a reference - the build script is removed afaik) is the opposite of what TypeScript did. If you broke someone's N-API module because of a regression not caught by your suite they're now between a rock and a hard place.
The good news is that there's nobody there to notice. The bun userbase is miniscule* compared to TypeScript's.
* negligible? irrelevant? laughably small? I'm struggling to find an adjective that does the difference justice.
That "incidental compatibility" point is a good place to start. Unless there are serious gaps in the test suite, one can have high confidence that there's no regression from the pre-fork version in documented behavior.
What kind of migration path beyond 0 regression do you think is needed? And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? And what kind of release are you expecting when the team is working to fully migrate to the port (so far it's still marked canary)? If someone's using an untested (ie. very likely unpublished) API, well it sucks to be them but they should know the risks.
And again the self-contradictory argumentation. If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless. No ecosystem worth giving a migration path and nobody's N-API module breaking because of a regression, right?
And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN?
Where did I ever claim this? I said they don't even have the Zig build script in their repo anymore - they're clearly not intending to make any more changes to it, even if the code is still lying there next to the Rust code.
If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless.
They're not criticisms, they're observations. The point is that the challenge is not comparable - because TypeScript's existing ecosystem is part of their challenge.
IMHO it's not the same car, even if its engine initially was a 1:1 rebuild using other alloys. But you're right I overstated and made myself look dumb (by a lot really - this is nothing like having 2 independent C compilers for instance).
What's taken 1:1, deliberately, was the compiler core. That was almost perfectly 50% of the non-test code. A close translation of that was a starting point, but open CHANGES.md or it's history and you'll see it's quickly diverging even on its surface.
The closest matching, interesting large area of it is probably the checker. Easily recognizable on a function level, even if not being a single file anymore:
You'll find a lot of the same data structures (as far as that's possible in a TS-to-Go translation + ripples from areas that were more heavily changed) and functions lying around, just in slightly different places. Because of the AST changes and TS/Go differences on a line-level each function might look different, but where there is a loop in the TS one, there's probably one in Go.
The other half of the project is heavily changed or completely new/different (like concurrency, less weird language service).
tech dept is not a problem. to paraphrase captain Jack sparrow. "even if it were the most indepted working software project, IT WORKED".
On the other side of the medal we have a rewritten software that although it's trumpeted for it's rewrite speed, it is not showing the same Release speed as the manualy written, "tech dept ridden" old one.
The author's assumption is that a rewrite is not just a mechanical translation of code - it's also a state of stability. And no release, for the author (I agree) means no stability.
It's like a developer who says that after a week of work, a feature is 90% ready, but the other 10% is still not ready (for release) after months.
Various people have claimed that Bun in Zig had a lot of tech debt. If they’re to be believed,
This is one of the funnier takes on the rewrite. Bun was held up as a flagship Zig project for years. Then they chose to rewrite in Rust and everyone up to the Zig author has suddenly switched to claiming that Bun was terrible code all along.
If what they're claiming is true then what were they supposed to do? Go "Hey guys, it's the biggest project in Zig and it sucks, don't look at it"? Not exactly a good PR move.
I didn't follow the thing too closely when it happened. Sure, I was aware of the big picture. But wow, I didn't expect that after all this noise there still hasn't been a release? That's just crazy to me.
I shouldn't be surprised though, of course. Giving any credit or slack to a high-valuation LLM company is a silly endeavor.
E.g. we should keep our wits about us when someone is making big hyperbolic claims about LLM that they directly benefit from, because maybe they have a motive to mislead either themselves, or us
I'm not sure how much insight we can glean from looking at the number of commits and release cadence here. In the aftermath of such a major refactor/rewrite, I would expect it to take some time to get back up to their usual development speed.
Jared and the other developers are new to the Rust codebase, even if the structure is largely familiar. They're also likely focusing on other priorities right now such as tracking down instances of 'unsafe', rather than making user-facing changes (which might encourage a release).
Bugfixes could encourage rapid new releases, but perhaps the rewrite simply hasn't been very buggy? As far as I know, those on the canary channel haven't reported any major issues, or even really noticed the change. So perhaps there's little reason for new releases right now, as the team slowly churns through the backlog.
P.S. Anthropic’s C compiler and Cursor’s FastRender web browser haven’t had any commits for months.
I always assumed those were just experiments in capability, and weren't meant to be ongoing projects. I would hope that nobody is using them directly today.
Look, I understand being skeptical of the whole process; the discourse about this has been extremely tiring.
But at some point if “moving one of the biggest actively maintained and used codebases to it without anyone noticing” is dismissed as “it doesn’t mean all that much”, then we’ve lost the plot a little bit somewhere.
It's the equivalent of porting Unreal Engine 5 to another language and then using it exclusively to run a 2D Tetris clone. Let's wait for the next Bun release when more real-world code is hammering it before declaring victory.
(also, fwiw, a manual rewrite would be under the same scrunity and suffer from the same skepticism, at least when obviously rushed).
If you could successfully write Tetris in Malbolge, I would call that impressive indeed. Just writing Hello World was a major effort IIRC. The nature of the malbolge interpreter makes it more of a cryptography exercise than a coding one.
I'm gonna jump in here with some self promo - back in college I TA'd a class that, for a few weeks, taught Malbolge, and the only assignment was for students to write a program that printed their name.
After spending a lot of time thinking about the language, I came up with a relatively simple algorithm based on the language design - there are a few operators that mutate state, so basically just try combinations of those until your next memory cell contains the thing that you want, then lock those instructions in and advance.
BUT! The whole reason for this comment is to nerd say that printing stuff is relatively easy if you invest the time in learning the language's primitives and think of programming in it more as algorithms to operate on the op codes instead of literally writing code.
Now, to do more interesting things other than printing - I'd have to spend even more time thinking about the language, which I don't want to
LLMs are very impressive. Five years ago, the idea that we'd have software that you could ask - in English, mind you! - to rewrite an entire server side JS runtime and you'd get something which even kind of worked was squarely in the realm of science fiction. But the question isn't "is this impressive?", but rather "should the results of such a rewrite be relied upon?" (and specific to this thread, "is the fact that a use case which only touches a small subset of the features of said result appears to no be completely broken good evidence it should be?")
A human doing it is impressive. A human performing many computations a computer could do would be impressive. I don't get impressed when a computer computes a number. A language machine translating is just... doing what a language machine does? When a language machine starts doing something other than translation, I will be impressed. If computers starting singing without any human intervention, for example, would be incredible! C3PO knows many languages—he may know Rust and Zig. C3PO translating from Zig to Rust isn't surprising to me. Sounds par the course for a robot who knows languages.
A language machine translating is just... doing what a language machine does?
Really? We had language machines for decades that couldn't do it. One that could was only built in the last 2 years max but that's something you expect from language machines? Lol Okay
This is akin to saying "we replaced the tires on the car and the average user didn't notice". If the entire car was replaced, then maybe we get a bit more excited.
However if "replacing small sections of code" is heralded as "the most amazing achievement in software development" then we've all lost the plot a little bit somewhere.
It makes sense both ways, no?
The reality is, of course, most people aren't going to notice. If the functionality and performance is 1:1 why would they? Is it impressive? A bit, but not how you're positioning it. People seem to forget LLMs are good at what they've learned from training data. And the LLM is good at compressing time. The only notable thing about these types of marketing spins is that a rewrite was accomplished in a small time frame that was hard to pull off before LLMs. The actual act of the move is less so.
Did the codebase improve? Is it more performant? I've seen nothing to really stake those claims with any objectiveness. Lastly: what was gained?
Claude Code client isn't one of the biggest actively maintained and used codebases. If it is one of the biggest, that's showing AI's tendency to waste its own tokens and your money.
Claude Code is 150k lines of Javascript that doesn't work particularly well. 150k isn't nearly "one of the biggest", even when filtering for actively maintained.
Claude code interacts with many system processes, files, etc, as well as external APIs. Processes audio via built in dictation. Manages a bunch of nasty auth. Etc etc.
What are the categories of features that wouldn't be exercised by this class of software?
Yeah, but a lot of hard work is done by those libraries. Interaction with external interfaces would go through the tools API, which I imagine would all use the same type of code that they could focus on fixing quickly.
This is probably a stupid question - as I’m totally unfamiliar with how interpreters call into system APIs - but would those calls use the bun runtime or the JavaScript Core engine the bun runtime wraps?
A bigger factor is that Claude Code is owned by Anthropic. They can view issues in the combined CC+Bun as issues in one overall thing that they own. They can reproduce and test them and "Claude Code works" can be used as a target for agentic iteration on Bun.
To release this to the world and not have it be a catastrophe, they need to have confidence that Bun itself satisfies the promises that it has made, both explicitly and implicitly (bearing in mind Hyrum's law!) to all those projects out there using it, none of which are owned by Anthropic and many of which are not source visible to them. It's a much, much higher bar.
You didn't seriously expect Anthropic to seriously maintain bun as a general purpose plattform? It's clearly the Claude Code Runtime that you're graciously allowed to continue to use for your toy projects.
Claude Code is a large codebase and uses tons of Node’s features either directly or indirectly through dependencies. fetch(), node:http, node:tls, node:os, node:net, node:fs, AbortSignal, node:child_process, node:tty, node:process, node:http2, etc.
Claude Code has a huge userbase. This is an impressive result so soon after the rewrite.
This is an impressive milestone for their rewrite. There are a lot of comments trying to downplay this as being unimpressive for some reason, but I can’t see them as anything other than sour grapes because the rewrite hasn’t crashed and burned like they were hoping.
It's just blind AI hate for no rhyme or reason. I've ported projects from one language to the next using Claude Code long before Bun even did this, it's very trivial for an LLM. In the case of Bun though, they have a test suite to run the entire codebase against, and so long as all of those tests pass, there's and drastically more likely chance that its correct.
The LLM translation of serenity brower's javascript engine to rust and bun's translation to rust actually provide an interesting set of open source projects to compare and contrast. While there will obviously be some blind hate, there is difference in commentary on the two projects. In technical details, Adreas'/Jared's approaches and communication. That all shows me there is substance to the criticism that isn't just AI naysaying.
I don't see the multiple dramatic comments to the effect of "this whole thing was a failure" as a level skepticism. While I am sure that one exists, I've noticed another wave of Rust hate hopping on that event which is honestly just sad to watch at this point.
If that is true, isn't it a bit unconventional? What version are they using, some random Git SHA? Why couldn't that have been made to a release or a release candidate at least?
Author here: I'm also not sure how much we can glean from any of that!!! I look forward to Anthropic or Bun releasing a retrospective after their next release that fully outlines the cost.
Given their history with previous other marketing stunts I do not expect any retrospective. The technology is real but I have little faith in open and honest communication from Anthropic.
truth. We'll just have to wait and see what the frequency and severity of bug reports is going forward. I have my biases, but I'm not going to make any forecasts here. I'm content to let the evidence dribble in. However, I don't rely on Bun for any critical systems. i.e. I realize it's easy for me to have a wait and see attitude with this one.
The CI/CD costs are an interesting take, most of the rebuttals to AI ROI are something like “more code doesn’t mean more value!” but if you are charging per CI run then it actually does! Particularly with CI and extra testing being the main way to prevent the loops the AI companies are shilling from going off the rails
I'm not sure Anthropic even cares about "releasing" the next version. The rust one has been in use in Claude Code for more than a month now, used by millions of people, and that's as far as they probably really worry about it. They bought Bun for Claude Code and I doubt the open source project matters to them otherwise.
I very much doubt they would want to abandon the wider community. They do benefit from others using it.
To the contrary, I think any problem with this release would be jumped on harshly so they're being more careful than usual. There's not a rush for the community to move to 1.4 and any issues could poison the community trust.
Do these hacks make bun less secure than other runtimes? I find it a little hard to believe you can get much more robust and performant than V8 or SpiderMonkey without cutting some corners that notably went uncut by either for all these years.
Bun uses JavaScriptCore, which is Safari’s JS engine, for the actual interpreter portion of its runtime.
Which makes the parent comment’s “Bun performance hacks and optimizations” sound a little far-fetched, at least in this scenario I don’t think that’s gonna be the deciding factor. Their vendored JSC is also not touched by this port-rewrite at all whatsoever (still Cpp), so I’m not sure if it’s even possible to hack-improve all that much there.
yes, especially compared to deno bun does not have proper isolation or permissions at runtime layer which is why anthropic tries to fix the lack by a mixture of app layer (build into claude code) and os layer (srt) however using runtime permissions would allow much better security if done right.
They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.
That's such a stupid engineering choice that it really makes one question if the people working at Anthropic have any software engineering ability at all. There's no excuse for running React in a freaking TUI.
Which is equally terrible and has earned them every single rendering engineer in the world taking the piss out of them when they proudly announced it was as complicated as rendering a video game.
They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.
The source of the performance issue here is their own incompetence, actually. I have never in my entire career heard of a rendering pipeline as idiotic as the custom one they built.
It's just a marketing stunt. They've got the ad for Claude-powered code rewrites, and that worked beautifully. Everyone got the message: spend big bucks with Anthropic to get rid of whatever codebase bugs you - please, think of the IPO!
If it was about Claude Code itself, they could have rewritten it. They keep saying they don't even write code any more, so it shouldn't even matter what language it's in.
If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust? That likely would be far more efficient than changing the language of your typescript runtime that ships to run your react-based CLI app.
I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.
If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust
Rewriting a runtime with well-defined interfaces and behavior is quite different from rewriting a user-facing application under active development by a decent chunk of their organization.
I agree, but this difference is very frustratingly omitted from the hype-sphere surrounding the rewrite, even though most software developers don't work on a runtime with well-defined interfaces and behavior. I know a number of people who've developed severe FOMO that their projects take longer than 2 weeks and maybe it's because they're not AI native enough.
(I don't mean to be critical of the Bun maintainers, who have always been open about the fact that they leveraged the specific context of their project to do this effectively.)
If you look at the reasons for rewriting Bun [0], they weren’t about efficiency and they don’t apply to Claude Code. It’s already written in a memory-safe language, and doesn’t have to interface to a library with a tricky set of invariants.
It was never that large but it did have a shot at getting more popular - until this drama.
No one worth their salt is building on Bun anymore, the creators and maintainers of bun have demonstrated their complete lack of care around engineering and support. It’s just too risky.
If you install bun you're still getting the zig version.
I don't see major reasons to doubt the rust rework, especially as so much capital and token investment is being thrown at it.
You shouldn't trust the rust rework. Despite the mountains of capital and token investment which have been thrown at it, they still only ship the zig version to users.
I really do not understand how software developer think anymore. Using a LLM to translate a project in a short time, is by itself incredible. Just like one-shot whatever office clone.
But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work.
I have used LLMs to create stuff like word clones just for fun. It was a disaster. Sure, it had the basic functionality. But the moment you started with page structure (harder then one non-stop scrolling page), tables, images, rotating, and so many details that make up just the basics of word. Not even the extended functionality. You see every LLM just fall on its face.
Sure, i can clone sqlite from c to rust. Hell, i may even get it to do all the tests 100%. But there is a 99% chance that the clone will be slower, as it lacks the years of optimizations from the original language. There will be new bugs because of the language changeover. There is a need for future support and fixes.
People threat software like its something it is not. But unlike the past where your clients question your sanity for charging 100k for a piece of software. Not understanding its not just about writing the code. Now those expectation are even more pushed forwards, because of articles like this.
I constantly see software being published on reddit that does X, Y, Z only for the authors to abandon it as fast as they vibe coded it. Because fixing bugs is NOT sexy. Even with a LLM at your fingertips. Dealing with nagging users, is not sexy. Dealing with security issues, is NOT sexy. Dealing with data structure / databases, especially as your system changes ... you get the point.
Not understanding to the core the software you wrote, is going to exploded in your face.
This is why these stupid "we rewrote X into Z with a LLM in Y days" mean nothing. Its one thing to get a head start using this trick, its another to actually learn the code of your rewrite. And dedicated the time into maintaining the port, growing it, fixing it. This is where a lot of software fails. But now this crap is out there, instead of the maintained version of Zig, now we have a unmaintained Rust version that clouded the airwaves because if people now search for it, those articles "X in Z days" will pop up.
I have used LLMs to create stuff like word clones just for fun. It was a disaster. Sure, it had the basic functionality. But the moment you started with page structure (harder then one non-stop scrolling page), tables, images, rotating, and so many details that make up just the basics of word. Not even the extended functionality. You see every LLM just fall on its face.
edit: Yeesh, misread your comment as "word games" not "word clones" and was very confused about the claim. Probably should have noted my confusion and re-read.
Nonsense. Provide/create proper tests for all features, and let the LLM test and fix everything.
In case of ccc (claudes C compiler) they just did not use any tests, though they are many existing C testsuite. They just stopped, when it finished compiling the kernel, still failing hundreds of tests.
Are you comparing 2 relatively simple games with... Word?
Word is basically an operating system. Unix people like to make fun of Emacs for being one, but Word is basically one, too. And all the features in there are used, otherwise Microsoft wouldn't keep them around.
That was certainly true once, but now all that state is serialized to xml amd zipped up. You can unzip it and look at it if you don't value your sanity.
If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era.
I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS. A dozen people or so could even run Firefox! I remember (now legend) Terry bothering us to check out LoseThos or GodOS or whatever was its name, but quite a few people had OSs that could do more than that.
Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished.
Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished.
This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.
This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.
Almost all of my prototypes are made this way.
"I made this in a weekend", is more often, "I made this in a day".
Like any trad-coded project, time to vibe code a backend vs frontend time is 1:N
This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop
This is exactly the same as demanding, that people who post their thoughts always post original, useful thoughts. It's just not going to happen. Making something easy will increase the total volume and the majority of that volume will be junk. It's inevitable. What is needed is a search engine for quality software. Perhaps LLMs can do that, since they are better at understanding concepts than generating them.
If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era.
Yeah, but the people authoring those learned something.
I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS.
Great example! I, too, once had my own toy OS, and browsed OSDev wiki nonstop. The thing is no one in the OS dev community were writing things they intended to place in front of actual users!
The difference now is that these incomplete projects:
a) Don't leave their owners any wiser than when they started, and
b) Are actually intended by their owners to be used by actual users.
I have learned a lot from those experiments, even if they're not polished.
Would you have learned as much if you told a magic box "Make me an OS" and then slapped your name on it and uploaded it to GH?
Probably not, but sometimes I wonder if the lowered activation bump lets more people try it, even if they just vibecode the whole thing, and maybe learn a thing or two in the process? They wouldn't learn as much as they would if they did it by hand, but they would've never done it by hand in the first place - so this is better maybe? I don't know. The whole field is in a weird place right now, all previous rules of thumb might be wrong.
My gut says there are fewer people in that group than there are people who would've learned something who now decided learning something isn't worth the effort. A net loss.
The more technical you get, the more subsitutable you become - or at least, people think of it in that way, because the whole idea is "It's not me, or the people, it's the raw technical prowess that earns its keep in this place".
But it seems like we're finally starting to accept that "accidentals" like network effects, ownership, accountability, etc. are important. Of course, that's why many of us fled to technical corners in the first place - because the "accidentals" become tied up with things like nepotism, unfair and arbitrary judges from random humans who don't understand your merit, the need for bullshitting more than real technical value. Supposedly, anyways.
My thoughts too. The LLMs made me understand that the world had been working like that long before LLMs. Luck plays an enormous part in life. We gravitated toward a discipline that seemed free of all those problems, when in fact it had those downfalls better disguised.
It’s strange how you think AI is some static thing that only produces the type of output you experienced and isn’t constantly improving. My experience has proven the latter time and time again.
Also I think porting code to another language or rewriting is one of the easier tasks for an LLM, since it has an extremely detailed spec (the source code itself) and a ton of tests already (hopefully).
In my experience, it will go to every length to convince you it has ported code that it hasn't. It will silently drop upstream unit tests it has no code for, if questioned it will insert some markdown giving some rational why that specific bit was deferred, after the fact, and then point you to it. This was Opus 4.6 for reference. I have had much better luck with small numbers of higher level tests that I can individually verify equivalency. I haven't tried having it do differential fuzzing on some high level interface, that seems like it might work in some cases. But to summarize, treat it like an adversary trying to deceive you.
Thank you for saying this! Every now and then I start to feel like I'm either the only sane person left or I must have gone insane and don't realize it.
LLMs amazed us and we've been trying to find a good use for them since and there's a lot things like this, replacing a transpiler with a non-deterministic machine that just guesses when it doesn't know the answer.
Shouldn't we be targeting LLMs at problems that traditional software absolutely can't handle?
Its one thing to get a head start using this trick, its another to actually learn the code of your rewrite.
I worked for a startup that stopped feature development and did a complete rewrite of a huge codebase. I was assigned to a side project during this time and missed the entire rewrite process. I came back to a completely rewritten codebase.
There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.
If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch.
I think they did it the right way based on my pre-LLM. Rewriting into a different language as fast and basically as possible is important for getting the team switched over quickly. Rewriting into a different language in X days is actually a good goal to minimize.
There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.
If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch
They eventually might regret this, when they are trying to get rid of the last lines of unsafe code. Rust needs to be written differently before you can write safe things to perform fast when compared to other languages or unsafe code. It takes a lot of experience before you can see it.
If this were a major issue then you'd have to always nail your Rust architecture correctly from day 1 to handle future unknowns, and this isn't the case.
More importantly, LLMs are more than capable of figuring out how to rearchitect code and they have no problem making sweeping refactors for you, especially throwaway experimental ones that were way too expensive to do not long ago.
I'd like more people to be writing about this, because I find it fascinating. I have my own private project that is heavily LLM-coded, just to learn about what it's like. It's amazing how everything is different yet everything is the same. Big complicated features can start working quickly and give a massive endorphin boost, but then fixing them up and integrating them in properly and polishing the UI? It all feels even more painful having experienced the heady thrill of the initial implementation. And things get to a point where you can feel the inertia set in, the point where things have gotten so hacked up that the LLM can't make any progress without creating an even bigger mess. It's the point where you have to go back and fix up the architecture, or scrap the whole thing and restart with a better plan, or a bit of both (rewind to the "last sane point"). It's like developing with a jetpack -- you can go way faster towards your goal, and you can slam into walls way faster and more painfully too.
I think there are tons of learnings to be shared about how to do this stuff, but it seems like it's all blocked behind arguments over whether AI is the best or worst thing ever, and penis-measuring contents about how to hold the tool. The net benefit is a very open question, and both the doom and gloom perspective and the AI booster perspective are valuable and have a lot of things right. But there's a dearth of information about what things work, what things don't, what happens in the process of using AI, how to adjust one's behavior and which of those adjustments is harmful even if effective.
But then, I'm part of the problem. I keep meaning to write up a series of experience reports, but it's a lot of work. More fun to vibe a new feature into existence, or to finally fix a UI wart...
To build a robust piece of deep-functionality software (like an MS Word clone) with an LLM, you have to start from the underlying architectural decisions, particularly how data is structured and how it flows through the system.
If you have an LLM or human just start coding up something without nailing down those decisions first, then he/she/it will implicitly make those decisions arbitrarily in the moment (usually based more on pattern-matching than real weighing of alternatives) and the result will be a massive mess.
Ideally for an LLM, you'd hand-write a highly detailed DESIGN.md file to encode those decisions and a suite of test fixtures to enforce them.
Part of what's nice about AI is that I don't feel that bad about pulling out and rebuilding some new feature that the AI has put a lot of time into but that I personally haven't. It let's me explore certain approaches and not feel tied to certain decisions that I might have not been confident about at the outset.
A fundamental miscommunication seems to be what part people are interested in. Just because I like to bake cakes doesn't mean I want to grow and mill my own wheat. Just because I like to make programs doesn't mean I want to tyoe code or learn the details of some library.
Everybody who has rewritten software understands the current phase: it mostly works, but there are always things to fix to make sure that there are no regressions, and the pressure is huge for any release.
I still believe it was the good decision, but I also know that I wouldn't be the first person to run the release in prod.
I think Jarred should start making release candidates instead of releases to take some of the pressure off.
This doesn't answer the question posed in the title unfortunately. I am none the wiser about how it's going. The author just speculates that the rewrite isn't actually complete.
I don't get it. Because they haven't cut a new arbitrary version number, we're denying it got done (in their perspective) and being used in a massive product already?
If you're being pedantic, no it's not "done," but nothing ever is.
It's not "done" if it's not stable and released. It's being canary tested by Claude Code users essentially but it's still being heavily worked on with tons of $ being poured into it and there's still no sign of them considering it stable and ready to go. That's the point of the article.
I am fascinated by the discourse around this Bun rewrite. I read a lot of drama and personal accusations, there are pieces like this one trying to extract clues, and it seems everyone has a deeper ideological concern behind whatever they are trying to say. For this article, it seems to be skepticism towards AI and how successful it can be at replacing programmers. Other takes, like the one from the Zig maintainer, were also along those lines but more about the open source ethics and the future of that in a LLM world.
I am mostly bullish on AI capabilities, so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that. Good follow-up questions would be how expensive it currently is to do so, and whether we will see people branching into all-in on AI versus no-AI camps as happened in this case.
You see this response because the port of Bun from Zig to Rust does not have anything to teach us about Zig, Rust or porting between languages with LLMs.
There are so many non-quantifiable properties to evaluate of the 'before' and 'after' codebases. Choices and preferences to be had about languages, language porting in general, and LLM coding.
After all that, pretend we could have a clear convincing distillation of the port and want to go apply the lessons learned. If someone doesn't get LLM porting results as good as Bun did, or it cost them substantially more in tokens, then they're "holding it wrong." If someone is underwhelmed by Bun's results, then it was just a proof of concept and the models have gotten so much better in the last 6 months anyway you can't compare.
so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that
There's a laundry list of reasons to be skeptical about LLM results in general. The biggest one is that LLMs are excellent at creating output that looks right but is nevertheless still wrong.
In this particular case, there's also a specific reason: This is obviously a marketing stunt regardless of whether the claimed results hold up. Anthropic has a long history of just lying and making shit up, so any results are subject to extra scrutiny.
For me this is how all workflows with AI end up lookingif you really want robust products. Do whatever with AI, go fast (from the point of view of perception, initially) BUT it is not going to work without extra work.
and ho, the bloat, do not forget the bloat, which is technical debt towards the future.
I am not anti-ai per-se, but I consider the software I write as a prouct to add features to and maintain over time. So in this case I think it is not wise to say that bc you got something impressive fast you are done. Now you have bugs, architecture, bloat removal, and others...
Letting an AI manage all the workflow is a recipe for disaster in anything that is not strictly short-term. For this reason, I hardly code one-off scripts myself anymore and I hardly use AI for big things besides discussions with the prompt, reviews and snippets. For adding tests it can also be useful.
For full, long-term products, they try to sell agents, and tokens and the like. I think they do not work well enough what I tried. It always ends up as a bloated unmantainable mess.
Unless something that is totally autonomous (by this I mean 100% autonomous) and automated ever exists, I see writing software that can be maintained by humans still critical. As long as this exists, the productivity upper bound will be that of humans reviewing and driving the workflow, even if with AI support.
I'm gonna say it bluntly: I don't care about bun, never cared about bun and think nodejs is sufficient. The drama surrounding zig and rust still leaves me with a bad taste because I also don't like how nonsensical topics like that influence what we do and what we (have to) care about on a day to day basis. That is just my opinion!
Mechanisms of beliefs, sense of identity and pride are behind of majority of projects including opensource. These are the same mechanisms which produce what you call "drama".
We can't have commited and involved people working on opensource stuff and simultaneously avoid drama when their sence of identity/beliefs/pride is devalued.
Nope, they want shared artifact(s) between web and desktop (not sure what do they have in mobile apps) clients (Chat/Cowork/Code/CC-cli), so TS is the way to go. It’s a reasonable choice made by engineers.
So you think if a company can't spend 1 million USD on a rewrite which has almost zero impact on performance, possibly net negative on maintainability it also can't have 500k LOC codebase either? Oh come on...
Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall.
In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likely next Tuesday we’ll do the release of 1.4.
CI has always been expensive for Bun including before the acquisition. We build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64] and then run tests on multiple Linux distros with multiple shards, multiple macOS versions and Windows for each architecture.
We recently started cross-compiling all the builds on Linux arm64 and that made it a little faster (I wrote a CLI tool to download the correct macOS headers for cross-compilation). We also have a daily cron job that asks claude to make the slowest tests faster while adding more assertions.
Presumably because they "build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64]" and self hosting all of that would be time-consuming and expensive.
Probably because they don't want to self-host Windows or MacOS servers when they can pay someone else to do that for them (or Linux ones, I assume that is within their wheelhouse for production but CI is a bit of a different beast to model inference).
It spawns ephemeral EC2/Azure instances, which is a lot cheaper than the GitHub actions runners we used before that.
We shard to a lot of machines for tests and I’d be worried about running out if we used dedicated servers.
BuildKite is fine but I wouldn’t be that surprised if we move off of BuildKite to a custom thing at some point. Months ago, we switched from CMake to a handrolled typescript build system and it made our builds faster and simpler.
codex trivially built me a self-hosted gh actions runner workflow for ephemeral vm's (just a big bash script that manages the vms with qemu). i even sped up the builds with my own custom base image with everything installed in it that i need too.
it works flawlessly.
fanning that out to starting and stopping instances wouldn't be too much of a stretch.
I think the question for CI costs is still out there. While I do not think it should be in tunes of thousands a day but thats the skepticism presented in the article. True costs are really important to make a good decision in situations like this. One has to consider the fact that lots of people are going to use these numbers to justify the rewrite in future.
Take as long as you need to ensure software quality. A month without a release isn't a big deal and whomever needs a specific feature can offer to contribute or build themselves.
Node has 4-6 weeks without a meaningful release (other than security stuff) pretty much every December. I think the criticism in the article is unfounded and whomever needed/wanted a release should have asked first instead of writing an "angry" blog post.
Author here: I don't need or want another Bun release or an NPM release or anything like that. Like I very clearly say in the article I just got chatting with a peer about the Bun rewrite and I decided to take a look.
I'm consistently skeptical about new tech whether it is NoSQL or Blockchain or Serverless. Some of the things I'm skeptical about fail and some succeed.
The bun Port is a phenomenal engineering achievement that would have taken a team of people over a year or two to deliver previously - look at the TypeScript port for example (and they had llms).
The fact it's taking a while to release is still insanely fast. I'm sure they may be some bumps.
Being skeptical is good and some stuff succeeds and some doesn't - but building tools is still fun and cool, whether it's useful or widely adopted or not :)
Text imports (experimental), native addon ESM support, blob textStream(), ReadableStreamTee, byob for readFile, better event loop monitoring and lots of security fixes as well as more minor bug fixes and improvements. (Last 4-6 weeks)
They declared bankruptcy on the original code base so hard that they decided to chuck it all in the trash. I wouldn't hold my breath expecting support for their existing users.
Jarred, thank you for working on Bun. Many "vibe coded" :D projects start strong and are later abandoned (like potentially Anthropic C), so I understand why people worry about Bun's future. I hope Bun lasts for many years, like GCC. Bun is fast and great to use.
I guess I'm debating, but it seemed clear enough to me? It proved that AI models and their harnesses are to the point where you can give them some work to do and leave them unattended for a long time, and they'll keep doing productive work for quite a while. This was a novel thing, and quite unclear, at the time the experiment was performed.
Obviously, the word "productive" is doing a lot of work there, but in my understanding the intention was nowhere near "commercially viable" or "practically useful", it was more like "not doing stupid shit like writing comments of the form 'This file contains the implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation ...'".
Maybe somewhere in the vicinity of "either passing more tests or generating more valid tests"?
The issue is that the Claude's C Compiler repository does not explicitly identify the project as a proof of concept. It was largely produced by one person directing Claude, and Bun's Rust rewrite also seems to have been driven by roughly one person using Claude Code. That similarity is what worries me. Bun's rewrite could also turn out to be proof of concept.
It was a commercial slogan for a toilet cleaning agent. An English equivalent would be "mr clean recommends you use mr clean". Today, it is used to point out when someone tells you they themselves delivered good work. Anytime you'd use the meme of Obama giving himself a medal, you could use this phrase.
Actually the existence of the French name is confusing for English speakers as although many would know enough school French to get "canard" == "duck" if prompted, in English this word ends up meaning some sort of fabrication or hoax, apparently from an old French joke where somehow that punchline of that joke was popularized in England so long ago we don't have records. Human culture is weird.
So the first thing an English native might get from "Canard WC" is probably hoax toilet, I expect the duck imagery of the product would bring the "canard" == "duck" meaning across though.
I don't see how it does. Claude Code is an extremely widely used product; the preceding comment offered an objective evaluation target, not a "trust me it's good" argument.
I don't see how Claude code being a widely used product is relevant to the person who orchestrated the Rust rewrite of bun saying that the orchestration of the Rust rewrite of bun went well. Wc eend is a widely used product as well, if that helps.
Ah, for context, which I suspect you may be unaware of, Jarred (the person who said the rewrite to rust went well) is the creator of bun, and the guy behind the rewrite.
I think the chain of reasoning is not hard to follow:
1. Assume the Rust rewrite of Bun went badly
2. Then something must be grievously wrong with a released bun runtime based on that code
3. Claude Code uses the released bun runtime based on that code
4. From #2 and #3, something must be grievously wrong with Claude Code
5. If something were grievously wrong with Claude Code, users would reduce use of Claude Code and use alternative tools
6. From #4 and #5, users are reducing use of Claude Code and using alternative tools
7. Claude Code has wide use and use is growing across all software engineering verticals
8. #6 and #7 contradict
9. From the contradiction, the assumption in #1 is false
The parts that are not explicitly spelled out here are an exercise for the reader. It doesn't really matter if the guy who wrote Bun said this or my uncle said this.
Ok, thanks for explaining! Doesn't really explain how the wc eend expression _doesn't_ apply here (which would be hard to do, because it _does_ apply, since this is someone praising their own work, and it doesn't get more straightforwardly applicable than that), but I do really appreciate the effort.
I always thought it was common sense and just basic critical thinking to take people paid by Anthropic praising products of Anthropic with a grain of salt (and let's be clear, that's what this is), but apparently it's not.
- How many people have updated Claude/Bun to the latest version.
- How many subscribers care about reporting issues. Most of them are forced to use the tool against their will and have mentally checked out already. Why report issues if your employer values slop code anyway. Just log the hours and keep your head down. Maybe it is not expedient for the AI narrative to report issues!
- How many subscriptions are real vs. bulk distiller accounts.
- If subscriber numbers are inflated.
Judging by the weird Claude Code Github issues page, there are suspiciously few new issues: about 2 to 3 a day only vs. alleged subscriber numbers of 4 million.
I do not trust AI agents to run outside sandbox and use them only in dev container. I always use latest version available when I build container (once or twice a month). In my opinion it is to risky to allow auto update for SW which is released several times a week including weekends and is capable of/willing to do script kiddie pranks :-)
Well, OK, you do that. Many others don't. Not sure what your comment adds except saying "not everybody allows audo-update" which is IMO redundant and obvious.
That's not surprising. Claude code is buggy enough, and releases break things often enough, that I wouldn't expect users to distinguish bugs introduced by switching to rust-based-bun from the normal garden variety bugs.
I’ve come to just expect that my CC instance will randomly “blank” and that I have to resize my terminal / use page up/page down to get it to show again.
Supposedly they used a game engine to render their TUI but I’ve never had an FPS game do that.
I can count the number of times an @ file reference doesn't autocomplete on a hundred hands. Or how a rewind won't reset the "is this file Read" marker. Or how a Branch (forking a convo) takes literally 5+secs to run. Or how a slashcommand that's user-only will not work if its in the middle of a prompt. Or how ctrl-r search will match results that don't include any search terms. Or how you can't resume a branch given its session id.
Yes Boris, tell me more about how "coding is solved".
Edit: literally just now, while writing a claude code hook, opus5 gave me this LOC because apparently the changelog and what's in the transcripts _differs_; great docs d00ds.
# Present only for a subagent's calls. Both spellings accepted: the changelog
# names `agent_id`, transcripts use `agentId`, and we need not care which lands.
agent=$(printf '%s' "$input" | jq -r '.agent_id // .agentId // empty')
Claude Code is quite buggy but doesn't generally crash, which is what you would expect if it shipped an immature backend for a month. Maybe the rewrite is full of bugs and they happened to result in the UI glitches or trashed settings files or whatever other application-level bugs that Claude Code has routinely rather than crashes but that would be pretty surprising.
Ok, so you've just admitted that you have deployed thousands of lines of likely non-human reviewed LLM generated code (Bun's rust rewrite) to millions of client machines (via the Claude Code app auto-update) with significant local client access credentials, in a relatively quick and rushed manner.
What's stopping the LLM from having unscrupulously injected something nefarious into the codebase that you are unaware of?
What's stopping future updates from the LLM from doing the same?
Are you aware of the potential ramifications of deploying thousands of lines of non-human reviewed code to millions of users machines?
Are you happy to be personally responsible for the horrendous outcomes that could occur in these situations?
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
"I put it in the terms of use, so I am not responsible for what my poorly developer software does" only goes so far.
It could be argued, probably successfully, that this is a case of gross negligence and that Anthropic should be held accountable for harm caused due to their reckless actions.
Especially now that they have been made aware of the possibility, they also cannot claim ignorance of the potential issues.
Certain consumer rights, depending upon the country, also cannot simply be removed or waived due to a organisation's terms of use or implied contract.
I would be stunned if there was a single line of hand written code in the entirety of Claude code lmao. Or if more than 20% of the code had been read by a person at any point. Why would you expect your ai code harness to not dogfood?
This article could increase its credibility by being updated to acknowledge that Bun-on-Rust has been live in Claude Code itself since June 17th, and available as a canary release since it landed on main.
Rewrites of this scale certainly justify long canary release periods!
Anthropic is dogfooding this, the machine is still ticking along, and Anthropic employees are directly involved.
The problem is that your article's central claim is that there hasn't been a Bun release since the Rust rewrite - which can be read as implying that the rewrite hasn't been used in production.
But it's been used in production on millions of machines running Claude Code for over a month!
I think failing to acknowledge that hurts the credibility of the article. It's been a heated discussion point in this thread already.
Why are you resistant to adding a sentence to the article that notes that Claude Code uses the rewrite?
Do you think it would weaken the article?
When I said it would improve the credibility I did mean it. My instinct on reading the article this morning was "this person doesn't know that Claude Code runs on Bun, which weakens their credibility in presenting the argument they are making here."
I try not to publish articles that call out mistakes by other people just for the sake of it. I've written a fair amount about the Bun rewrite already - https://simonwillison.net/search/?q=bun%20rust
To me this seems like an odd preoccupation for an article that is very little about the Bun rewrite as a running program and very much about the process of the re-write and how it came to be in commits to the repository.
You could argue that the release tag isn't important - but at the top of this comment thread a member of the team confirms they delayed the release to finish some extra testing. So the ambiguity around if the project is complete and pointing to the lack of a release mirrors internal sentiment as well.
I had a funny thought that Bun might add a release tag while I was still writing the article. In that case I'd still publish it, because the point is we still don't know the cost it took to get to a viable, wide, release. The $165k isn't the full story.
Why are you resistant to adding a sentence to the article that notes that Claude Code uses the rewrite?
It's not your article, bud. They have already addressed your concerns, and don't need to make changes just because you feel the article isn't "fair".
My instinct on reading the article this morning was "this person doesn't know that Claude Code runs on Bun, which weakens their credibility in presenting the argument they are making here."
And your instinct was clearly mistaken. You should read the article more carefully before offering criticism.
I stand by what I said. I was offering honest advice: when I read the article I thought exactly that, and so did other people based on the comments in this thread - which I think shows my instinct has value here.
There's an easy fix. If they don't want to take my advice that's completely fine.
which can be read as implying that the rewrite hasn't been used in production.
Well it hasn't. "Production" for a language runtime means being generally available for arbitrary use. The engineers that built the runtime using it to release one closed source binary to the public is, at best, an extremely narrow beta test.
I get that there's a baseline of unsafe that's necessary, but I was under the impression that some of those unsafes were in places where they could be replaced by more idiomatic Rust at a later date.
I don't think that's true. I think a fair chunk of them are places where Bun is handed a pointer by WebKit or something similar. I believe they write about this a little.
I think there's a reasonable expectation that unsafe could still be reduced by having shared, safer abstractions - that would lead to fewer `unsafe` results because the `unsafe` would be contained. I'm surprised that this isn't a higher priority target for them.
The bun rewrite inspired me to be much more aggressive on porting code, rewriting code, or vendoring external dependencies to tailor them specifically to our needs in ways that doesn’t make sense to upstream.
I feel like it made me generally more ambitious in what I’d throw at a coding model, but also made me focus a lot more on our testing harness and keeping a lot of it at the boundaries outside the language specific parts.
Having been part of several huge rewrites before, some multi-year long, I definitely would consider bun’s rewrite an enormous success. To keep such a level of test and feature parity, and add improvements on top of it, is a massive engineering feat.
As a comparison point, someone decided to try to fix the issues in the Zig original and is now claiming sub-second build times, plus fixed bugs, by modernizing the codebase and sticking with best practices - indicating that all of the issues that justified the rewrite were self-inflicted and addressable.
I have no skin in this game, and the Zig version is also using LLMs if that helps take the culture war out of it. But, it has always been true in my experience that someone who really understands a problem space can outcompete someone who just throws resources (in hundreds of thousands of dollars of token spend) at it.
indicating that all of the issues that justified the rewrite were self-inflicted and addressable
The main issue that justified the rewrite were memory bugs, especially related to interaction with GC managed Javascript objects. There is no fully general way to prevent those bugs in Zig, and I don't see any claims that they did so in Buz.
They also complained about build times, and in fact the Rust rewrite started immediately after some other drama about Bun being unable to contribute back LLM-written changes to the Zig compiler to improve build times, and the Zig team rejecting them in principle. So while memory issues did become the focus later, I don't think it was the entire story.
Migrating to Rust in a one-to-one translation with unsafe blocks does not make the code any more safe initially. It might provide tools to do a significant refactor that solves lifetime issues with Rust's help, but I haven't seen evidence that they've done that either. They're also embedding a large C++ codebase, JavaScriptCore, so there are always going to be unsafe areas and touchpoints where memory issues could live, and Rust won't magically solve them.
It wasn’t just on principle that those changes were rejected, they also stated the bun changes were not actually that great or general enough to upstream.
Bun is the quintessential AI slop project at this point. Inheriting that is no easy task. I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape. It will likely require most subsystems to be rewritten.
They're refusing to accept human-authored contributions. They're using LLMs to do the work. The author says they'll use LLMs to de-slop what they think is slop, and humans are banned from contributing.
Self-hosting a language used to be standard practice. These days that's become a bit more controversial, but I definitely wouldn't lump that in as a sign of obsession.
I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code. So I'm not sure I trust it just because tests pass. I also think that tests do not and cannot check everything.
I also don't trust it just because it compiles in Rust. The Rust compiler does not check everything.
So at what point do projects like this cross from "untrusted" to "trusted"?
That makes sense to me as a tactic to prevent that problem.
But the article talks about how so much code was written so fast. Seems to me that to create that much code that fast you have to have AI produce both the code and the tests.
So I am not sure in this project if the AI can edit the tests or not. I assume that because this is Anthropic the AI is doing as much as possible, which would include editing tests.
Bun had an enormous existing test suite written in TypeScript. Getting those tests to pass against the Rust version was the key thing that enabled the project.
You can go and check if the AI edited the tests yourself: look at the git history of those files in the public Bun repository.
But Bun also implements the interpreter to those tests— doesn't that mean it has a lot of leeway to over-fit to them? It's not as clean as "don't change these files" in this case.
In general I would agree though, and would take it one step further: the agent writing the source code should not even be able to see the tests, nor the agent writing the tests see the source code.
The Rust compiler suffers from a number of crash bugs and nondeterminism, and they won't accept AI diagnoses or fixes, so Rust has become an unreliable partner for software development.
If you're going to do serious development with Rust, I suggest forking the compiler. Upstream your fixes to a fork which takes AI contributions, or fork your own. Or keep all of your improvements private, that works just fine.
I don't quite understand the focus on the token cost of this rewrite. Obviously, we should examine if this rewrite is good, effective, good for the product etc., but the token cost seems ... not important?
The marketing value of this to Anthropic (if Anthropic even cares, this might just be the Bun team selling past the close) is to show that such a rewrite is possible and delivers engineering value. If exactly this project is $800K today, it'll be $200K and then $80K soon, so it's not so important to the story that it's cheap, just that a big "cool" rewrite is possible, and delivers velocity to the buisness.
I think, we all are phrasing this wrong. Bun was <strike>rewritten</strike> retooled in Rust by AI with only ensuring integration tests and usage tests succeed. That's similar how to a C program was compiled to binary or Typescript was transpiled to Javascript and run. We didn't make a very big deal of it then, and I think, we should see this operation as a similar higher level source to source translation, which machines have been doing.
I just got a github notification on an old Bun bug report when it was still coded in zig. The bun-bot had completely solved the bug in the new rust codebase, added comprehensive tests, did the write up, pushed the commit all without human interaction. The fix looked sound and changed minimal lines of code. This AI is the real deal. Programmers should be concerned.
Any runtime written in a compiled language gets translated to completely different language in seconds every time it is built! That is what should already terrify you. :)
I can see CI battling pretty hard with rusts slow compile times but not sure that is particularly conclusive of anything when it comes to the success of the rewrite
Jarred from Bun is in this comment section saying the rewrite isn't finished yet. I therefore don't consider it a failure or a success. I'll be keen to see how much the CI cost though since that's a part of the cost of the rewrite.
If you’ve ever worked at a tech company you already know the answer without reading any further
Yeah, the answer is that it's gonna working fine for most users.
Author here: An apology on the graphs, they just count rust files touched in commits, not total commits. So if there were two commits and one touched 3 .rs files and another touched 2, it'd be counted as 5 for the purposes of the graphs. I may fix this later but, yeah.
what kind of difference from the actual numbers does it result in?
Not sure! I cludged together a counter using git log. I could go back and redo it but I think the number would serve my point either way.
Hope you find that job :) nice work experience, looks very ethical focused.
I did suspect that the triumphalist pronouncements, and even the seemingly honest and forthright deep dive, were a little premature.
This is a key problem with LLM exuberance: it's very tempting to trade on decades of experience in software using LLMs, because one is tired of typing and manual figuring-out, it seems to work if you're competent, and the payoff is essentially immediate. The real bill comes in the mail much later.
I consider typing to be secondary to software engineering, but I do concede that for those cases that typing really is the bottleneck, LLMs can certainly be of value.
Those cases are rare, though.
Oh, I 100% agree. I'm imagining the case where someone asks an LLM to do trivial things just for the novelty, or because they are fatigued of thinking + typing, but conceptualise the thing they are putting off as primarily a problem of typign and not thinking (I often do that).
This is so real now that we have LLMs. The stuff I'm working on doesn't seem to exist in LLM training sets, but I still get tempted to try when I get tired of doing the tedious parts.
Many repeat the point of “$165k is cheaper than team of multiple engineers working on the rewrite for a year”, which I think is flawed — the team of engineers would have produced idiomatic rust, and it would take probably 100k+ of tokens more to make the bun in rust idiomatic rust.
I feel your estimate of tokens is a few orders of magnitude off, it’s on the low side.
I use more (albeit cached) when centering a div.
I think they missed a $ sign, i.e. they meant $100k of tokens
100k tokens is your pre-prompt and your CLAUDE.md as well as a few files from your root.
This is where we've come to where people proudly proclaim using an AI to do what is a single line of CSS.
"centering div" is a classic problem (/trauma/meme) that sounds trivial but had no universal solution (until 2017?).
And has a dead simple one today.
Also worth noting simple horizontal centering of divs was never a problem, margin: auto was defined in CSS Level 1 in 1996 [1].
It was vertical centering that took a very long time to crack, which really became trivial with Flexbox which was first drafted in 2009[2] but became available unprefixed in browsers between 2012 and 2014 [3] about 13 years ago.
[1] https://www.w3.org/TR/REC-CSS1-961217
[2] https://www.w3.org/TR/2009/WD-css3-flexbox-20090723/
[3] https://caniuse.com/flexbox
Subnote: I'm not counting the display: table hacks.
What a great joke.
I will have to steal it for an upcoming AI tools meeting I have at work.
Also, pretty clever as centering a div w/ CSS has been notoriously difficult to achieve.
I keep seeing this. What is "un-idiomatic" rust?
Presumably lots of stuff wrapped in 'unsafe'. I'm not a rust guy or a rust fan, and the last time I wrote something with Rust was like 7 years ago, but to my memory, because of how Rust manages mutability there are many access patterns that are Rust-specific; idiomatic Rust is going to use this patterns but they would be unlikely to show up in a language with a different type system / borrow checker / etc. etc.
So "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?'
How odd. Lot of mental gymnastics going on there.
It's mostly the same in any general purpose programming language though, parts of the language features are meant (or became seens as) tools to be used in very narrow cases, which people less familiar with the language tend to "overuse".
Eg. goto/jump, bare "except" statements in python, etc... In Rust, unsafe has its uses and is a first class language feature, but it certainly isn't idiomatic to use it to mimic access patterns from other languages (unless absolutely necessary).
The Bun author himself writes that the port is not idiomatic Rust:
(from: https://bun.com/blog/bun-in-rust)
The original version of Bun was already a line-by-line (manual) port of esbuild from Go to Zig (also mentioned in this post), so the Zig code already wasn't "Zig-idiomatic" and apparently riddled with problems. That doesn't inspire much confidence in the LLM-translated Rust version tbh.
And yet Claude Code, which is the primary consumer, continues to chug away without any issue (that I, as a fairly heavy user, have encountered).
It means "don't misuse parts of the language in ways that circumvent best practices" one of which is "keep unsafe regions as small and few as possible" not "never use unsafe"
Meh. The (a major?) goal of Rust is this sort of type safety flowing down to memory bugs. Not every possible access pattern was known at the beginning, and generally they developed a philosophy of keeping the "unsafe" memory access patterns extremely bounded and heavily inspected. I think that's a fair and admirable goal.
that is indeed a roughly accurate definition of what "unidiomatic" means
Rust contains the ability to do everything that C can, if you use `unsafe`. And a file-by-file rewrite in Rust from another language usually involves keeping the ABI and API between files very C-like (and unsafe). In practice this means that the result of a first pass this way has all the memory safety of C code, but with worse readability because Rust makes unsafe things less ergonomic.
To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.
I don't think this latter stage has actually happened with Bun's codebase. The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).
Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).
An LLM definitely can do that work, but LLMs have a tendency to follow the path of least resistance unless you force them to do things properly and carefully supervise them.
That's a really strong motivation for the Rust port. It's literally impossible to take a path not leading to an unacceptable outcome because the Rust compiler fails the compile if code no longer marked "unsafe" is still actually unsafe, and the tests fail if the implementation is incorrect. The compiler actively helps to force the LLM to do things properly.
…only if you actually force the LLM not to use `unsafe` somehow! And one must remember that `unsafe` can have all sorts of non-local effects. One way to be maliciously compliant (or in the LLM's case, I guess it's more incompetence than malice) is to make a “safe” function that does an `unsafe` operation for you, and then replace every usage of that unsafe operation with your “safe” function. You can remove hundreds of unsafe blocks that way without any improvement in safety.
Yeah this is going out of scope now. The in-scope safe/unsafe is that which is specifically recognized by the Rust compiler (literal greppable keyword). With that and the tests weighing I'd say it's pretty difficult to be incompetent, as the correct path becomes the easy path. Even if the LLM were to somehow go the maliciously compliant route I'm thinking it'd burn so many beyond-expected tokens trying to get around both compiler and tests that it'd be caught.
You can use deterministic linting for `unsafe` usage, have agents target `unsafe`, etc. It's pretty easy. You can even run `miri` against the code and give that as a tool for LLM feedback. I've done this all before and it works fine.
I'm unconvinced that this is true. How could you tell? You only know about the rust bugs because rust makes them grep'able/ trivial to verify, there's no way of knowing which bugs existed in zig that didn't translate. Regardless, the problem is now trivial to understand in Rust and start to target.
They also would have produced a team of engineers that knows the Rust codebase.
This is assuming your engineers don't leave for higher-paying roles elsewhere. The market might be cold generally but for engineers working at these frontier AI companies it's red-hot.
And most executives are figuring this into their calculus right now because they were burned badly during COVID. Meta, Google, etc were loose with hiring and engineers flocked from their lower-paying companies in droves. The brain drain was real.
One public company I was at lost nearly 2/3rds of their engineers and mostly to Meta (granted, they had other problems but it was mostly about money -- the offers were excessive). Then market conditions forced them to freeze hiring and they've had a slow exodus of senior talent since as the firefighting has become constant.
AI adoption has only accelerated problems for them.
We've taken this "only two years and then leave" philosophy to an extreme and now companies are totally justified in not investing in their engineers anymore.
The job-hopping followed from companies not investing in their engineers, not the other way around. It was billed as the only way to get a promotion (which usually would come every 1-2 years).
I've been in this industry for a few decades at this point and I was around when this meme was started.
It was purely about maxing your compensation because changing jobs nets you more than promotions & raises.
I've never met an engineer in my life who truly earned a promotion every year and very few every two. Very few companies have org charts that even support that or have that many levels. This logic/advice only really applies at a few companies and people have adopted it no matter where they work. There's not enough growth/hiring at 95% of companies to even come close. The Peter Principle is also a real thing. Everyone's competence has a ceiling.
There's even an implicit understanding of this that people at smaller companies have inflated titles and you typically rank them down 1-2 levels when hiring/acquiring at larger companies.
Now I do agree that companies haven't been investing in their engineers, but that doesn't also mean this isn't a vicious cycle. Employers and employees are in a mexican standoff and things are only going to get worse until one side comes to its senses. Employers have all the leverage for it to not be them.
For the vast majority of companies the average tenure of an engineer sits between 18 and 30 months. They're also mostly hiring young engineers in their 20s. As an employer what is your upside to making such investments before they're at least mid-career? A lot of people seem to want the world and offer nothing in return for it.
You don't view it as a problem that companies consistently compensate new hires higher than they are their experienced employees?
Hell, I would have been perfectly happy to never change employers in my entire career to date, if my salary had anywhere near kept pace with my peers who were job-hopping.
It depends on the current employee and the incoming employee. They are not interchangeable cogs. Also not everyone consistently provides good value over their tenure -- a lot tend to work hard early and then for various reasons taper off. It's not necessarily their fault, but companies definitely are aware of this.
Personally I tend to value growth of my skillset over growth of income and that has largely informed my movement. I move when there's no longer interesting work if the compensation is at least fair. I've never been about comparing myself to others -- especially when most of my peers' left the industry after 5-10 years.
And you don’t think that has anything to do with incentives (or lack thereof)?
Doesn’t have to be about comparing oneself to others. More about the cost of living increasing because software engineering salaries are rising around you…
I currently work at a company where the average tenure is somewhere around 7 years. Wanna know their crazy secret? They don't treat their employees like disposable cattle, and actually invest in them! Our salaries go up yearly a few % above inflation as the bare minimum, we have great benefits, there's no crunch or overworking culture etc. It's a company with ~5000 employees globally too, not a tiny startup burning cash.
I'm similar to many people, I wouldn't have left some jobs in the past had I been treated with a modicum of respect and if my compensation went up with my tenure. But time and time again, pay ranges go up as new hires join in, but you're treated like you're insane for asking your compensation as a senior to match the compensation of a newly joined junior.
"Knowing the codebase" seems like an antithetical philosophy to LLM driven engineering orgs.
Well the purpose of the tool is to automate more specialized labor so any knowledge that could benefit the worker has to be downplayed or stigmatized.
I doubt file by file rewriting takes as much work as rewriting and refactoring the code - especially at this scale.
Would they have, in a year? The general plan of attack would likely still be the same: rewrite it in rust while keeping the structure as similar as possible, no matter how unidiomatic, then adjusting the design to make it more idiomatic to rust. Doing both at once is much harder.
I think with sequential approach (translate -> make idiomatic) it is easier. However, I am not sure that monetary difference is going to be as stark as $165k vs 3 engineers/year. Especially, if you consider that no one knows that is what in the code at the end.
Sure, you can argue that now it doesn’t matter — agents and all that, but I am not so sure.
Yes this is a typical case of showing results fast. I wonder what the cost for the remaining 10℅ of debugging and fixing all the bloat will be. Not so cheap I am guessing
IMO a team of engineers (presuming this is pre-AI) would have improved the existing Zig codebase, rather than spent time and money on a Rust port in the first place. In fact, I still think most teams of engineers would choose to improve what they have even now, circa AI.
Yes, and curiously many of the tellings of this story don't account for the costs of the human software engineers (Jarred and the other bun team members) who guided all of this work.
Not necessarily. Didn’t Microsoft port the TS compiler to Go and they did it by translating the TS? It wasn’t idiomatic Go.
This post doesn’t make sense. It was rewritten in Rust. The rewrite itself is complete (no more Zig).
Various people have claimed that Bun in Zig had a lot of tech debt. If they’re to be believed, it seems natural to assume the rewrite does, too. Perhaps all this activity is paying down some of that debt.
Perhaps. But were that the case, one would think they'd be quite eager to say so.
Maybe they will!
Are you expecting them to live-tweet their work or something?
jared was OK making this rewrite as an experiment branch in the public
why shouldnt upcoming work be as public as the rewrite itself was?
You may continue to hold your breath. You may die as a result. The maintainers continue to do what they want regardless.
I do not really care, just pointing where people's assumptions might be coming from.
The beauty of FOSS tho is Jarred owes the community nothing, and anyone can fork bun previous to migration and keep maintaining it on zig if they so wish.
long live open source
Based on the way they live-tweeted (as it were) their rewrite and their other publicity stunts? Yes, actually.
bun in zig was used by many companies. some were using it in prod. how many of those are using it in prod? none, because bun in rust is not released yet.
Hence, the author concludes that rust rewrite is not complete as bun in rust is not released yet.
I agree with author's POV.
The rust version is being used by Claude Code though - which is a fairly large product!
I was hoping for more push back against https://bun.com/blog/bun-in-rust - which is pretty thorough and has some decent arguments and reasoning for why they did the rewrite.
I think they meant “released and available for use” rather than just out in the wild.
It is available for use: `bun upgrade --canary`
it doesn't imply that lot legacy apps won't crash in prod when it will be actually released. Cool that some complex app is working but is nothing proving that everything will be fine when everyone will try to upgrade.
Yeah, but it's a TUI that has more bugs and worse performance than any other TUI in history. It's not like we'd notice a user after free.
How much of the Bun/Node API surface does Claude Code actually use though? Conceptually it's a relatively simple TUI application.
Author kept "going" in title because there has been no minor/major release in last two months which unusual for this project if you review the older releases.
A major rewrite in another language is also unusual for this project.
It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0. That work was done in parallel; here the work is being done serially — and it’s likely to take much less than a year for a new release.
Yes, its because Anthropic took over and wanted to showcase their LLM capabilities by porting such a complex codebas.
Everyone’s point is “they have everything to gain by lying about being more done then they are” and “the claims seem at least a bit full of shit”.
These are not comparable at all. The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem.
TypeScript 7.0. by comparison is not just a translation from one language to another. It's a true rewrite that at the same time has to consider a massive existing ecosystem (which needs to catch up first or you risk fragmenting it). Plus you might as well consider 6.x part of the effort, since that was the stepping-stone.
Also where bun really is just a runtime implemented with a bunch of glue code plus supporting tooling, TypeScript is much more complex. Change one part of TypeScript and you can get cascading issues somewhere else in the compiler easily. Change something in Bun and you'll likely just break some discrete part.
This seems self-contradictory. If it's just a translation, doesn't that mean it remains fully compatible with that wider ecosystem? All the existing APIs retain identical behavior given the preexisting comprehensive test suite that had to go 100% green after all.
It's not.
Passing an existing test suite just moves the optimistic lower bound to incidental compatibility, it doesn't move it to intentional - "regard" implies you gave it thought.
Plus, it's not just about code: it's also about giving the ecosystem a migration path. Dumping 500k LOC on people and discontinuing development of the zig version effective immediately (there hasn't been a release since and the zig tree is only a reference - the build script is removed afaik) is the opposite of what TypeScript did. If you broke someone's N-API module because of a regression not caught by your suite they're now between a rock and a hard place.
The good news is that there's nobody there to notice. The bun userbase is miniscule* compared to TypeScript's.
* negligible? irrelevant? laughably small? I'm struggling to find an adjective that does the difference justice.
That "incidental compatibility" point is a good place to start. Unless there are serious gaps in the test suite, one can have high confidence that there's no regression from the pre-fork version in documented behavior.
What kind of migration path beyond 0 regression do you think is needed? And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? And what kind of release are you expecting when the team is working to fully migrate to the port (so far it's still marked canary)? If someone's using an untested (ie. very likely unpublished) API, well it sucks to be them but they should know the risks.
And again the self-contradictory argumentation. If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless. No ecosystem worth giving a migration path and nobody's N-API module breaking because of a regression, right?
Where did I ever claim this? I said they don't even have the Zig build script in their repo anymore - they're clearly not intending to make any more changes to it, even if the code is still lying there next to the Rust code.
They're not criticisms, they're observations. The point is that the challenge is not comparable - because TypeScript's existing ecosystem is part of their challenge.
TypeScript 7.0 was literally a line by line translation. With essential features necessary for adoption still like a year off.
It's funny, but a large reason for why Go was chosen was explicitly because it has semantics close to TypeScript and that made it automatable:
https://github.com/microsoft/typescript-go/discussions/411#d...
So basically the opposite of what you're saying.
IMHO it's not the same car, even if its engine initially was a 1:1 rebuild using other alloys. But you're right I overstated and made myself look dumb (by a lot really - this is nothing like having 2 independent C compilers for instance).
What's taken 1:1, deliberately, was the compiler core. That was almost perfectly 50% of the non-test code. A close translation of that was a starting point, but open CHANGES.md or it's history and you'll see it's quickly diverging even on its surface.
The closest matching, interesting large area of it is probably the checker. Easily recognizable on a function level, even if not being a single file anymore:
https://github.com/microsoft/typescript-go/tree/main/interna...
https://raw.githubusercontent.com/microsoft/TypeScript/refs/... (The TS file is 3MB and github won't display it inline)
You'll find a lot of the same data structures (as far as that's possible in a TS-to-Go translation + ripples from areas that were more heavily changed) and functions lying around, just in slightly different places. Because of the AST changes and TS/Go differences on a line-level each function might look different, but where there is a loop in the TS one, there's probably one in Go.
The other half of the project is heavily changed or completely new/different (like concurrency, less weird language service).
tech dept is not a problem. to paraphrase captain Jack sparrow. "even if it were the most indepted working software project, IT WORKED". On the other side of the medal we have a rewritten software that although it's trumpeted for it's rewrite speed, it is not showing the same Release speed as the manualy written, "tech dept ridden" old one.
The author's assumption is that a rewrite is not just a mechanical translation of code - it's also a state of stability. And no release, for the author (I agree) means no stability.
It's like a developer who says that after a week of work, a feature is 90% ready, but the other 10% is still not ready (for release) after months.
This is one of the funnier takes on the rewrite. Bun was held up as a flagship Zig project for years. Then they chose to rewrite in Rust and everyone up to the Zig author has suddenly switched to claiming that Bun was terrible code all along.
If what they're claiming is true then what were they supposed to do? Go "Hey guys, it's the biggest project in Zig and it sucks, don't look at it"? Not exactly a good PR move.
I didn't follow the thing too closely when it happened. Sure, I was aware of the big picture. But wow, I didn't expect that after all this noise there still hasn't been a release? That's just crazy to me.
I shouldn't be surprised though, of course. Giving any credit or slack to a high-valuation LLM company is a silly endeavor.
It was expected. These LLM rewrites seem to work amazingly at first and then you realize there is a ton of work remaining.
What a time to be alive
Yeah, I noticed that too and kept wondering who this Canny was that the author wants to be? Felt a bit un-Canny...
More proof that it was written by a human!!!
Still have no idea what that means…
https://www.merriam-webster.com/dictionary/canny
It means shrewd.
E.g. we should keep our wits about us when someone is making big hyperbolic claims about LLM that they directly benefit from, because maybe they have a motive to mislead either themselves, or us
Came to point this out as well. Very bizarre that it was capitalized. Italics or bold might even have been acceptable...
I'm not sure how much insight we can glean from looking at the number of commits and release cadence here. In the aftermath of such a major refactor/rewrite, I would expect it to take some time to get back up to their usual development speed.
Jared and the other developers are new to the Rust codebase, even if the structure is largely familiar. They're also likely focusing on other priorities right now such as tracking down instances of 'unsafe', rather than making user-facing changes (which might encourage a release).
Bugfixes could encourage rapid new releases, but perhaps the rewrite simply hasn't been very buggy? As far as I know, those on the canary channel haven't reported any major issues, or even really noticed the change. So perhaps there's little reason for new releases right now, as the team slowly churns through the backlog.
I always assumed those were just experiments in capability, and weren't meant to be ongoing projects. I would hope that nobody is using them directly today.
They also have made a release, in a sense, since they moved all Claude code users to it a month ago. (And apparently no one noticed).
I think they're taking things "gradually" as they are under a lot of scrutiny and no rush for full release.
Claude Code most likely only uses a tiny fraction of Bun/Node features, so Claude Code switching to the Rust rewrite doesn't mean all that much.
Look, I understand being skeptical of the whole process; the discourse about this has been extremely tiring.
But at some point if “moving one of the biggest actively maintained and used codebases to it without anyone noticing” is dismissed as “it doesn’t mean all that much”, then we’ve lost the plot a little bit somewhere.
It's the equivalent of porting Unreal Engine 5 to another language and then using it exclusively to run a 2D Tetris clone. Let's wait for the next Bun release when more real-world code is hammering it before declaring victory.
(also, fwiw, a manual rewrite would be under the same scrunity and suffer from the same skepticism, at least when obviously rushed).
Is it though? What’s your source for that data?
If you ported UE5 to, idfk, Malbolge and ran Tetris on it and someone would dismiss it as “not impressive”, I would think they lost the plot too!
You just compared Rust to Malbolge :)
If you could successfully write Tetris in Malbolge, I would call that impressive indeed. Just writing Hello World was a major effort IIRC. The nature of the malbolge interpreter makes it more of a cryptography exercise than a coding one.
I'm gonna jump in here with some self promo - back in college I TA'd a class that, for a few weeks, taught Malbolge, and the only assignment was for students to write a program that printed their name.
After spending a lot of time thinking about the language, I came up with a relatively simple algorithm based on the language design - there are a few operators that mutate state, so basically just try combinations of those until your next memory cell contains the thing that you want, then lock those instructions in and advance.
Basically RNG yourself to victory.
The original code for that algorithm is here (python, + my own interpreter): https://github.com/wallstop/malbolge-toolkit/tree/dd942fb981...
I've since llmified it as an exercise.
BUT! The whole reason for this comment is to nerd say that printing stuff is relatively easy if you invest the time in learning the language's primitives and think of programming in it more as algorithms to operate on the op codes instead of literally writing code.
Now, to do more interesting things other than printing - I'd have to spend even more time thinking about the language, which I don't want to
LLMs are very impressive. Five years ago, the idea that we'd have software that you could ask - in English, mind you! - to rewrite an entire server side JS runtime and you'd get something which even kind of worked was squarely in the realm of science fiction. But the question isn't "is this impressive?", but rather "should the results of such a rewrite be relied upon?" (and specific to this thread, "is the fact that a use case which only touches a small subset of the features of said result appears to no be completely broken good evidence it should be?")
"I ported .NET framework to x86 bare metal. Here's hello world as proof."
"I ported .NET Framework to x86 bare metal. Here's proof using Hello World."
A human doing it is impressive. A human performing many computations a computer could do would be impressive. I don't get impressed when a computer computes a number. A language machine translating is just... doing what a language machine does? When a language machine starts doing something other than translation, I will be impressed. If computers starting singing without any human intervention, for example, would be incredible! C3PO knows many languages—he may know Rust and Zig. C3PO translating from Zig to Rust isn't surprising to me. Sounds par the course for a robot who knows languages.
Really? We had language machines for decades that couldn't do it. One that could was only built in the last 2 years max but that's something you expect from language machines? Lol Okay
Eating a mountain one teaspoon of sand at a time is impressive too, but I don't see why it means I should respect the act.
You have absolutely no way to know this though.
Like, come on already.
This is akin to saying "we replaced the tires on the car and the average user didn't notice". If the entire car was replaced, then maybe we get a bit more excited.
However if "replacing small sections of code" is heralded as "the most amazing achievement in software development" then we've all lost the plot a little bit somewhere.
It makes sense both ways, no?
The reality is, of course, most people aren't going to notice. If the functionality and performance is 1:1 why would they? Is it impressive? A bit, but not how you're positioning it. People seem to forget LLMs are good at what they've learned from training data. And the LLM is good at compressing time. The only notable thing about these types of marketing spins is that a rewrite was accomplished in a small time frame that was hard to pull off before LLMs. The actual act of the move is less so.
Did the codebase improve? Is it more performant? I've seen nothing to really stake those claims with any objectiveness. Lastly: what was gained?
Why is porting a program from one language to another seen as some great achievement? We had f2c in the 1990s.
https://en.wikipedia.org/wiki/F2c
This isn't a valid comparison. f2c is a compiler and the output isn't intended to be human readable.
Plenty of people telling us not to bother reading code output by LLMs
Claude Code client isn't one of the biggest actively maintained and used codebases. If it is one of the biggest, that's showing AI's tendency to waste its own tokens and your money.
Claude Code is 150k lines of Javascript that doesn't work particularly well. 150k isn't nearly "one of the biggest", even when filtering for actively maintained.
I'll bite.
Claude code interacts with many system processes, files, etc, as well as external APIs. Processes audio via built in dictation. Manages a bunch of nasty auth. Etc etc.
What are the categories of features that wouldn't be exercised by this class of software?
Yeah, but a lot of hard work is done by those libraries. Interaction with external interfaces would go through the tools API, which I imagine would all use the same type of code that they could focus on fixing quickly.
This is probably a stupid question - as I’m totally unfamiliar with how interpreters call into system APIs - but would those calls use the bun runtime or the JavaScript Core engine the bun runtime wraps?
A bigger factor is that Claude Code is owned by Anthropic. They can view issues in the combined CC+Bun as issues in one overall thing that they own. They can reproduce and test them and "Claude Code works" can be used as a target for agentic iteration on Bun.
To release this to the world and not have it be a catastrophe, they need to have confidence that Bun itself satisfies the promises that it has made, both explicitly and implicitly (bearing in mind Hyrum's law!) to all those projects out there using it, none of which are owned by Anthropic and many of which are not source visible to them. It's a much, much higher bar.
You didn't seriously expect Anthropic to seriously maintain bun as a general purpose plattform? It's clearly the Claude Code Runtime that you're graciously allowed to continue to use for your toy projects.
Claude Code is a large codebase and uses tons of Node’s features either directly or indirectly through dependencies. fetch(), node:http, node:tls, node:os, node:net, node:fs, AbortSignal, node:child_process, node:tty, node:process, node:http2, etc.
I've had several bun-related crashes in Claude code in the last week, which I don't remember ever seeing before then.
Does it print a bun.report link and can you paste it? I will investigate.
Claude Code has a huge userbase. This is an impressive result so soon after the rewrite.
This is an impressive milestone for their rewrite. There are a lot of comments trying to downplay this as being unimpressive for some reason, but I can’t see them as anything other than sour grapes because the rewrite hasn’t crashed and burned like they were hoping.
It's just blind AI hate for no rhyme or reason. I've ported projects from one language to the next using Claude Code long before Bun even did this, it's very trivial for an LLM. In the case of Bun though, they have a test suite to run the entire codebase against, and so long as all of those tests pass, there's and drastically more likely chance that its correct.
The LLM translation of serenity brower's javascript engine to rust and bun's translation to rust actually provide an interesting set of open source projects to compare and contrast. While there will obviously be some blind hate, there is difference in commentary on the two projects. In technical details, Adreas'/Jared's approaches and communication. That all shows me there is substance to the criticism that isn't just AI naysaying.
Seems to be more level skepticism to me. Not "blind hate".
I don't see the multiple dramatic comments to the effect of "this whole thing was a failure" as a level skepticism. While I am sure that one exists, I've noticed another wave of Rust hate hopping on that event which is honestly just sad to watch at this point.
I am sure we are both right though.
If that is true, isn't it a bit unconventional? What version are they using, some random Git SHA? Why couldn't that have been made to a release or a release candidate at least?
Author here: I'm also not sure how much we can glean from any of that!!! I look forward to Anthropic or Bun releasing a retrospective after their next release that fully outlines the cost.
Given their history with previous other marketing stunts I do not expect any retrospective. The technology is real but I have little faith in open and honest communication from Anthropic.
truth. We'll just have to wait and see what the frequency and severity of bug reports is going forward. I have my biases, but I'm not going to make any forecasts here. I'm content to let the evidence dribble in. However, I don't rely on Bun for any critical systems. i.e. I realize it's easy for me to have a wait and see attitude with this one.
There is no incentive for them to be honest about the downsides and problems.
The CI/CD costs are an interesting take, most of the rebuttals to AI ROI are something like “more code doesn’t mean more value!” but if you are charging per CI run then it actually does! Particularly with CI and extra testing being the main way to prevent the loops the AI companies are shilling from going off the rails
I'm not sure Anthropic even cares about "releasing" the next version. The rust one has been in use in Claude Code for more than a month now, used by millions of people, and that's as far as they probably really worry about it. They bought Bun for Claude Code and I doubt the open source project matters to them otherwise.
I very much doubt they would want to abandon the wider community. They do benefit from others using it.
To the contrary, I think any problem with this release would be jumped on harshly so they're being more careful than usual. There's not a rush for the community to move to 1.4 and any issues could poison the community trust.
Like this rewrite did not terminally poison trust?
Has it impacted your use case negatively?
Anyone know why? Can’t CC run on any JS runtime?
because their js code is so bad and slow that they need the bun performance hacks and optimisations.
Do these hacks make bun less secure than other runtimes? I find it a little hard to believe you can get much more robust and performant than V8 or SpiderMonkey without cutting some corners that notably went uncut by either for all these years.
Bun uses JavaScriptCore, which is Safari’s JS engine, for the actual interpreter portion of its runtime.
Which makes the parent comment’s “Bun performance hacks and optimizations” sound a little far-fetched, at least in this scenario I don’t think that’s gonna be the deciding factor. Their vendored JSC is also not touched by this port-rewrite at all whatsoever (still Cpp), so I’m not sure if it’s even possible to hack-improve all that much there.
yes, especially compared to deno bun does not have proper isolation or permissions at runtime layer which is why anthropic tries to fix the lack by a mixture of app layer (build into claude code) and os layer (srt) however using runtime permissions would allow much better security if done right.
Yes, but it’s slower on non-bun runtimes. Nowadays, I believe they bundle bun with CC
They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.
AFAIK, they have written a new renderer.
That's such a stupid engineering choice that it really makes one question if the people working at Anthropic have any software engineering ability at all. There's no excuse for running React in a freaking TUI.
Which is equally terrible and has earned them every single rendering engineer in the world taking the piss out of them when they proudly announced it was as complicated as rendering a video game.
The source of the performance issue here is their own incompetence, actually. I have never in my entire career heard of a rendering pipeline as idiotic as the custom one they built.
It's just a marketing stunt. They've got the ad for Claude-powered code rewrites, and that worked beautifully. Everyone got the message: spend big bucks with Anthropic to get rid of whatever codebase bugs you - please, think of the IPO!
If it was about Claude Code itself, they could have rewritten it. They keep saying they don't even write code any more, so it shouldn't even matter what language it's in.
If that is really what they are concerned with, they probably could have just had Claude Code rewrite Claude Code in rust? That likely would be far more efficient than changing the language of your typescript runtime that ships to run your react-based CLI app.
I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.
Rewriting a runtime with well-defined interfaces and behavior is quite different from rewriting a user-facing application under active development by a decent chunk of their organization.
I agree, but this difference is very frustratingly omitted from the hype-sphere surrounding the rewrite, even though most software developers don't work on a runtime with well-defined interfaces and behavior. I know a number of people who've developed severe FOMO that their projects take longer than 2 weeks and maybe it's because they're not AI native enough.
(I don't mean to be critical of the Bun maintainers, who have always been open about the fact that they leveraged the specific context of their project to do this effectively.)
If you look at the reasons for rewriting Bun [0], they weren’t about efficiency and they don’t apply to Claude Code. It’s already written in a memory-safe language, and doesn’t have to interface to a library with a tricky set of invariants.
[0] https://bun.com/blog/bun-in-rust
Why wouldn't they?
Bun is a major part of the web ecosystem, having it developed by them via AI, sounds like a gigantic pr win.
It’s not. Node is part of the web ecosystem. Bun was a way to upsell paas
It was never that large but it did have a shot at getting more popular - until this drama.
No one worth their salt is building on Bun anymore, the creators and maintainers of bun have demonstrated their complete lack of care around engineering and support. It’s just too risky.
I regularly use bun, it's a decisive speed improvement over node. Large parts of the ecosystem build on bun.
If you install bun you're still getting the zig version.
I don't see major reasons to doubt the rust rework, especially as so much capital and token investment is being thrown at it.
As long as it fits better than alternatives, I see no major reasons to change.
You shouldn't trust the rust rework. Despite the mountains of capital and token investment which have been thrown at it, they still only ship the zig version to users.
Why did they buy an open source project anyway? If is not “officially” supported why not fork and use? Claude code is probably the most used anyway
They bought the maintainers, not the code.
Why though? Isn't AI supposed to take care of such things?
Because even when the AI is really good at writing code, you still have to know what to ask it, how to direct it, have product taste, etc.
Otherwise all of us would just be able to build bun via a prompt.
To me it just looks like a marketing stunt.
I really do not understand how software developer think anymore. Using a LLM to translate a project in a short time, is by itself incredible. Just like one-shot whatever office clone.
But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work.
I have used LLMs to create stuff like word clones just for fun. It was a disaster. Sure, it had the basic functionality. But the moment you started with page structure (harder then one non-stop scrolling page), tables, images, rotating, and so many details that make up just the basics of word. Not even the extended functionality. You see every LLM just fall on its face.
Sure, i can clone sqlite from c to rust. Hell, i may even get it to do all the tests 100%. But there is a 99% chance that the clone will be slower, as it lacks the years of optimizations from the original language. There will be new bugs because of the language changeover. There is a need for future support and fixes.
People threat software like its something it is not. But unlike the past where your clients question your sanity for charging 100k for a piece of software. Not understanding its not just about writing the code. Now those expectation are even more pushed forwards, because of articles like this.
I constantly see software being published on reddit that does X, Y, Z only for the authors to abandon it as fast as they vibe coded it. Because fixing bugs is NOT sexy. Even with a LLM at your fingertips. Dealing with nagging users, is not sexy. Dealing with security issues, is NOT sexy. Dealing with data structure / databases, especially as your system changes ... you get the point.
Not understanding to the core the software you wrote, is going to exploded in your face.
This is why these stupid "we rewrote X into Z with a LLM in Y days" mean nothing. Its one thing to get a head start using this trick, its another to actually learn the code of your rewrite. And dedicated the time into maintaining the port, growing it, fixing it. This is where a lot of software fails. But now this crap is out there, instead of the maintained version of Zig, now we have a unmaintained Rust version that clouded the airwaves because if people now search for it, those articles "X in Z days" will pop up.
What have we become ...
What do you think of https://scramblequest.app and https://wordpeek.app ?
I have never looked at any of the code for them
edit: Yeesh, misread your comment as "word games" not "word clones" and was very confused about the claim. Probably should have noted my confusion and re-read.
Nonsense. Provide/create proper tests for all features, and let the LLM test and fix everything.
In case of ccc (claudes C compiler) they just did not use any tests, though they are many existing C testsuite. They just stopped, when it finished compiling the kernel, still failing hundreds of tests.
Are you comparing 2 relatively simple games with... Word?
Word is basically an operating system. Unix people like to make fun of Emacs for being one, but Word is basically one, too. And all the features in there are used, otherwise Microsoft wouldn't keep them around.
Haha, I misread as "word games" and was very confused about the claim.
And .doc files are basically a memory dump.
Dump is a great word for it
That was certainly true once, but now all that state is serialized to xml amd zipped up. You can unzip it and look at it if you don't value your sanity.
So what you're saying is that the files are basically a memory dump formatted as XML? :-p
A selective menory dump that when deserialized can ignore fields not present its version, but yeah.
That's why I said .doc. The format you're talking about is called .docx
I think they might mean Word as in Microsoft Word. Just based on the feature list they were describing.
I think this is perfectly fine.
If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era.
I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS. A dozen people or so could even run Firefox! I remember (now legend) Terry bothering us to check out LoseThos or GodOS or whatever was its name, but quite a few people had OSs that could do more than that.
Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished.
This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.
Almost all of my prototypes are made this way. "I made this in a weekend", is more often, "I made this in a day". Like any trad-coded project, time to vibe code a backend vs frontend time is 1:N
This is exactly the same as demanding, that people who post their thoughts always post original, useful thoughts. It's just not going to happen. Making something easy will increase the total volume and the majority of that volume will be junk. It's inevitable. What is needed is a search engine for quality software. Perhaps LLMs can do that, since they are better at understanding concepts than generating them.
Temple OS :)
That was half memory-loss, half joke, since Terry was always changing the OSs name. Wish he was still with us, renaming it every year!
Yeah, but the people authoring those learned something.
Great example! I, too, once had my own toy OS, and browsed OSDev wiki nonstop. The thing is no one in the OS dev community were writing things they intended to place in front of actual users!
The difference now is that these incomplete projects:
a) Don't leave their owners any wiser than when they started, and
b) Are actually intended by their owners to be used by actual users.
Would you have learned as much if you told a magic box "Make me an OS" and then slapped your name on it and uploaded it to GH?
Probably not, but sometimes I wonder if the lowered activation bump lets more people try it, even if they just vibecode the whole thing, and maybe learn a thing or two in the process? They wouldn't learn as much as they would if they did it by hand, but they would've never done it by hand in the first place - so this is better maybe? I don't know. The whole field is in a weird place right now, all previous rules of thumb might be wrong.
My gut says there are fewer people in that group than there are people who would've learned something who now decided learning something isn't worth the effort. A net loss.
I've built tools myself with AI assistance and I've learned a bunch, and will still keep learning.
LoseThOS didn't burn through hundreds of thousands of dollars of expensive and environmentally questionable compute.
True! It just burned though other forum contributors patience! I miss the Terry from back in the day (early 2000s?) though.
The more technical you get, the more subsitutable you become - or at least, people think of it in that way, because the whole idea is "It's not me, or the people, it's the raw technical prowess that earns its keep in this place".
But it seems like we're finally starting to accept that "accidentals" like network effects, ownership, accountability, etc. are important. Of course, that's why many of us fled to technical corners in the first place - because the "accidentals" become tied up with things like nepotism, unfair and arbitrary judges from random humans who don't understand your merit, the need for bullshitting more than real technical value. Supposedly, anyways.
I think it is a very good point: "because the "accidentals" become tied up with things like nepotism, unfair and arbitrary"
I never thought of this from this perspective but indeed it seems to be totally true.
My thoughts too. The LLMs made me understand that the world had been working like that long before LLMs. Luck plays an enormous part in life. We gravitated toward a discipline that seemed free of all those problems, when in fact it had those downfalls better disguised.
Also if you whip something up, you tend not to care for it as much as something you took the time to create in a "proper" manner.
It’s strange how you think AI is some static thing that only produces the type of output you experienced and isn’t constantly improving. My experience has proven the latter time and time again.
Also I think porting code to another language or rewriting is one of the easier tasks for an LLM, since it has an extremely detailed spec (the source code itself) and a ton of tests already (hopefully).
In my experience, it will go to every length to convince you it has ported code that it hasn't. It will silently drop upstream unit tests it has no code for, if questioned it will insert some markdown giving some rational why that specific bit was deferred, after the fact, and then point you to it. This was Opus 4.6 for reference. I have had much better luck with small numbers of higher level tests that I can individually verify equivalency. I haven't tried having it do differential fuzzing on some high level interface, that seems like it might work in some cases. But to summarize, treat it like an adversary trying to deceive you.
Not really. Transpilers have existed since forever.
The hard part is all the edge cases. (And LLMs don't solve this problem; they probably akshually exacerbate it.)
Thank you for saying this! Every now and then I start to feel like I'm either the only sane person left or I must have gone insane and don't realize it.
LLMs amazed us and we've been trying to find a good use for them since and there's a lot things like this, replacing a transpiler with a non-deterministic machine that just guesses when it doesn't know the answer.
Shouldn't we be targeting LLMs at problems that traditional software absolutely can't handle?
I worked for a startup that stopped feature development and did a complete rewrite of a huge codebase. I was assigned to a side project during this time and missed the entire rewrite process. I came back to a completely rewritten codebase.
There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.
If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch.
I think they did it the right way based on my pre-LLM. Rewriting into a different language as fast and basically as possible is important for getting the team switched over quickly. Rewriting into a different language in X days is actually a good goal to minimize.
They eventually might regret this, when they are trying to get rid of the last lines of unsafe code. Rust needs to be written differently before you can write safe things to perform fast when compared to other languages or unsafe code. It takes a lot of experience before you can see it.
I doubt it.
If this were a major issue then you'd have to always nail your Rust architecture correctly from day 1 to handle future unknowns, and this isn't the case.
More importantly, LLMs are more than capable of figuring out how to rearchitect code and they have no problem making sweeping refactors for you, especially throwaway experimental ones that were way too expensive to do not long ago.
Short-termism at its peak. Code maintainers will learn the hard way how to set the boundaries between ai-generated code, and human maintainable code.
I'd like more people to be writing about this, because I find it fascinating. I have my own private project that is heavily LLM-coded, just to learn about what it's like. It's amazing how everything is different yet everything is the same. Big complicated features can start working quickly and give a massive endorphin boost, but then fixing them up and integrating them in properly and polishing the UI? It all feels even more painful having experienced the heady thrill of the initial implementation. And things get to a point where you can feel the inertia set in, the point where things have gotten so hacked up that the LLM can't make any progress without creating an even bigger mess. It's the point where you have to go back and fix up the architecture, or scrap the whole thing and restart with a better plan, or a bit of both (rewind to the "last sane point"). It's like developing with a jetpack -- you can go way faster towards your goal, and you can slam into walls way faster and more painfully too.
I think there are tons of learnings to be shared about how to do this stuff, but it seems like it's all blocked behind arguments over whether AI is the best or worst thing ever, and penis-measuring contents about how to hold the tool. The net benefit is a very open question, and both the doom and gloom perspective and the AI booster perspective are valuable and have a lot of things right. But there's a dearth of information about what things work, what things don't, what happens in the process of using AI, how to adjust one's behavior and which of those adjustments is harmful even if effective.
But then, I'm part of the problem. I keep meaning to write up a series of experience reports, but it's a lot of work. More fun to vibe a new feature into existence, or to finally fix a UI wart...
To build a robust piece of deep-functionality software (like an MS Word clone) with an LLM, you have to start from the underlying architectural decisions, particularly how data is structured and how it flows through the system.
If you have an LLM or human just start coding up something without nailing down those decisions first, then he/she/it will implicitly make those decisions arbitrarily in the moment (usually based more on pattern-matching than real weighing of alternatives) and the result will be a massive mess.
Ideally for an LLM, you'd hand-write a highly detailed DESIGN.md file to encode those decisions and a suite of test fixtures to enforce them.
Part of what's nice about AI is that I don't feel that bad about pulling out and rebuilding some new feature that the AI has put a lot of time into but that I personally haven't. It let's me explore certain approaches and not feel tied to certain decisions that I might have not been confident about at the outset.
As I understand it, bun was already vibe coded so nothing of value was lost in vibe porting it to a different language.
A fundamental miscommunication seems to be what part people are interested in. Just because I like to bake cakes doesn't mean I want to grow and mill my own wheat. Just because I like to make programs doesn't mean I want to tyoe code or learn the details of some library.
Everybody who has rewritten software understands the current phase: it mostly works, but there are always things to fix to make sure that there are no regressions, and the pressure is huge for any release.
I still believe it was the good decision, but I also know that I wouldn't be the first person to run the release in prod.
I think Jarred should start making release candidates instead of releases to take some of the pressure off.
This doesn't answer the question posed in the title unfortunately. I am none the wiser about how it's going. The author just speculates that the rewrite isn't actually complete.
You and me both friend!
I don't get it. Because they haven't cut a new arbitrary version number, we're denying it got done (in their perspective) and being used in a massive product already?
If you're being pedantic, no it's not "done," but nothing ever is.
One single product, AFAIK, and one ladden with bugs and issue too.
It's not "done" if it's not stable and released. It's being canary tested by Claude Code users essentially but it's still being heavily worked on with tons of $ being poured into it and there's still no sign of them considering it stable and ready to go. That's the point of the article.
I am fascinated by the discourse around this Bun rewrite. I read a lot of drama and personal accusations, there are pieces like this one trying to extract clues, and it seems everyone has a deeper ideological concern behind whatever they are trying to say. For this article, it seems to be skepticism towards AI and how successful it can be at replacing programmers. Other takes, like the one from the Zig maintainer, were also along those lines but more about the open source ethics and the future of that in a LLM world.
I am mostly bullish on AI capabilities, so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that. Good follow-up questions would be how expensive it currently is to do so, and whether we will see people branching into all-in on AI versus no-AI camps as happened in this case.
No one on their team had Rust experience
You see this response because the port of Bun from Zig to Rust does not have anything to teach us about Zig, Rust or porting between languages with LLMs.
There are so many non-quantifiable properties to evaluate of the 'before' and 'after' codebases. Choices and preferences to be had about languages, language porting in general, and LLM coding.
After all that, pretend we could have a clear convincing distillation of the port and want to go apply the lessons learned. If someone doesn't get LLM porting results as good as Bun did, or it cost them substantially more in tokens, then they're "holding it wrong." If someone is underwhelmed by Bun's results, then it was just a proof of concept and the models have gotten so much better in the last 6 months anyway you can't compare.
There's a laundry list of reasons to be skeptical about LLM results in general. The biggest one is that LLMs are excellent at creating output that looks right but is nevertheless still wrong.
In this particular case, there's also a specific reason: This is obviously a marketing stunt regardless of whether the claimed results hold up. Anthropic has a long history of just lying and making shit up, so any results are subject to extra scrutiny.
"LLMs are excellent at creating output that looks right but is nevertheless still wrong."
"Anthropic has a long history of just lying and making shit up"
Every now and then I wonder, if LLMs were created by honest people would they be more honest themselves?
Just a couple more 100hr weeks of debugging, and the last 80% will be done :-)
For me this is how all workflows with AI end up lookingif you really want robust products. Do whatever with AI, go fast (from the point of view of perception, initially) BUT it is not going to work without extra work.
and ho, the bloat, do not forget the bloat, which is technical debt towards the future.
I am not anti-ai per-se, but I consider the software I write as a prouct to add features to and maintain over time. So in this case I think it is not wise to say that bc you got something impressive fast you are done. Now you have bugs, architecture, bloat removal, and others...
Letting an AI manage all the workflow is a recipe for disaster in anything that is not strictly short-term. For this reason, I hardly code one-off scripts myself anymore and I hardly use AI for big things besides discussions with the prompt, reviews and snippets. For adding tests it can also be useful.
For full, long-term products, they try to sell agents, and tokens and the like. I think they do not work well enough what I tried. It always ends up as a bloated unmantainable mess.
Unless something that is totally autonomous (by this I mean 100% autonomous) and automated ever exists, I see writing software that can be maintained by humans still critical. As long as this exists, the productivity upper bound will be that of humans reviewing and driving the workflow, even if with AI support.
I'm gonna say it bluntly: I don't care about bun, never cared about bun and think nodejs is sufficient. The drama surrounding zig and rust still leaves me with a bad taste because I also don't like how nonsensical topics like that influence what we do and what we (have to) care about on a day to day basis. That is just my opinion!
Mechanisms of beliefs, sense of identity and pride are behind of majority of projects including opensource. These are the same mechanisms which produce what you call "drama".
We can't have commited and involved people working on opensource stuff and simultaneously avoid drama when their sence of identity/beliefs/pride is devalued.
Something about bun always rubbed me up the wrong way (I even hate the name), but I couldn't really explain why.
Thankfully now I have some good material to post-rationalise my intuitive dislike
Maybe it would have made more sense for Anthropic to rewrite Claude Code in rust, and cut out the middle man (bun)?
Nope, they want shared artifact(s) between web and desktop (not sure what do they have in mobile apps) clients (Chat/Cowork/Code/CC-cli), so TS is the way to go. It’s a reasonable choice made by engineers.
Pretty sure rust can run on browsers;
The agent loop doesn’t run in the browser.
Maybe their “TUI-over-React” team doesn’t want to get fired because of AI, either?
The leaked code of the claude had switch flag where claude pretends to be employee. You can't trust/expect that those PR's were authored by people.
Oh, that company that I heard did not use humans aymore to write software and bragged about it? I heard, correct me if I am wrong.
Something does not match here...
That’s peanuts, if not the shells of the peanuts, for a project and company of this magnitude
How does that help 99.9% of all other companies though?
Some thoughts:
- just because it doesn’t help 99.9% of the companies today it doesn’t mean it won’t help them tomorrow
- 0.01% of the companies employ a much bigger percentage of people
- 99.9% of companies won’t need to do a project of this magnitude
So you think if a company can't spend 1 million USD on a rewrite which has almost zero impact on performance, possibly net negative on maintainability it also can't have 500k LOC codebase either? Oh come on...
This rewrite is showcased by Anthropic to sell AI rewrites to other companies.
If it turns out the rewrite cost stupid amounts of money and leads to a bad outcome, it's just a misleading ad.
We developers now need to explain that to illuminated management and colleagues.
Ohhhhh for a world where that's peanuts for an open source project.
Bun’s Rust rewrite shipped in Claude Code over a month ago and barely anyone noticed. Claude Code is widely used. The Rust rewrite is going well overall.
In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likely next Tuesday we’ll do the release of 1.4.
Any comment on the costs estimated in the article? especially the buildkite costs?
CI has always been expensive for Bun including before the acquisition. We build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64] and then run tests on multiple Linux distros with multiple shards, multiple macOS versions and Windows for each architecture.
We recently started cross-compiling all the builds on Linux arm64 and that made it a little faster (I wrote a CLI tool to download the correct macOS headers for cross-compilation). We also have a daily cron job that asks claude to make the slowest tests faster while adding more assertions.
How come Bun uses Buildkite instead of self-hosting the CI infra?
Presumably because they "build for [macOS, Linux, FreeBSD, Android, Windows] x [ARM64, x64]" and self hosting all of that would be time-consuming and expensive.
Probably because they don't want to self-host Windows or MacOS servers when they can pay someone else to do that for them (or Linux ones, I assume that is within their wheelhouse for production but CI is a bit of a different beast to model inference).
It spawns ephemeral EC2/Azure instances, which is a lot cheaper than the GitHub actions runners we used before that.
We shard to a lot of machines for tests and I’d be worried about running out if we used dedicated servers.
BuildKite is fine but I wouldn’t be that surprised if we move off of BuildKite to a custom thing at some point. Months ago, we switched from CMake to a handrolled typescript build system and it made our builds faster and simpler.
Thanks for answering!
I suppose my second question would be how much Bun spends on CI per month atm - I'd imagine that robobun would have ramped up the bill a fair bit
you don't need buildkite or blacksmith anymore.
codex trivially built me a self-hosted gh actions runner workflow for ephemeral vm's (just a big bash script that manages the vms with qemu). i even sped up the builds with my own custom base image with everything installed in it that i need too.
it works flawlessly.
fanning that out to starting and stopping instances wouldn't be too much of a stretch.
Does it work with macOS ?
weird question, i don't see why not. osx has a fantastic virtualization story.
https://developer.apple.com/documentation/virtualization/run...
I think the question for CI costs is still out there. While I do not think it should be in tunes of thousands a day but thats the skepticism presented in the article. True costs are really important to make a good decision in situations like this. One has to consider the fact that lots of people are going to use these numbers to justify the rewrite in future.
So are the "$800k + CI" estimates accurate? And your team works weekends just to make tests faster?
Take as long as you need to ensure software quality. A month without a release isn't a big deal and whomever needs a specific feature can offer to contribute or build themselves.
Node has 4-6 weeks without a meaningful release (other than security stuff) pretty much every December. I think the criticism in the article is unfounded and whomever needed/wanted a release should have asked first instead of writing an "angry" blog post.
(I'm a Node.js maintainer)
Author here: I don't need or want another Bun release or an NPM release or anything like that. Like I very clearly say in the article I just got chatting with a peer about the Bun rewrite and I decided to take a look.
I'm consistently skeptical about new tech whether it is NoSQL or Blockchain or Serverless. Some of the things I'm skeptical about fail and some succeed.
What are some of your favorite tools or services that you adopted in the past few years?
uv
That’s a great approach. No matter what you will always find a reason to be positively surprised!
The bun Port is a phenomenal engineering achievement that would have taken a team of people over a year or two to deliver previously - look at the TypeScript port for example (and they had llms).
The fact it's taking a while to release is still insanely fast. I'm sure they may be some bumps.
Being skeptical is good and some stuff succeeds and some doesn't - but building tools is still fun and cool, whether it's useful or widely adopted or not :)
The initial "10 days and $165k" was still a tad optimistic dontchathink?
Yeah if you want you can check out my github page to see some tool failures. Nobody is hyping those up, though.
The problem is what you’re skeptical about, the true cost, is probably the least important part.
Did it really cost $1 million instead of the 150k that’s been floating around?
If you don’t like the price now just give it some time.
The point is that these kind of heroics can actually work now and they’re only going to get cheaper.
I don’t mean to sound negative about what you wrote, it was an interesting read.
Personally I think the cost does matter.
What is Node getting every 4-6 weeks that makes it noteworthy when it doesn't?
Text imports (experimental), native addon ESM support, blob textStream(), ReadableStreamTee, byob for readFile, better event loop monitoring and lots of security fixes as well as more minor bug fixes and improvements. (Last 4-6 weeks)
Another functional way to iterate over an array
Any chance for 1.3.15 with bugfixes for the rest of us?
Yeah, 1.3.14 has some bad regressions. 1.3.11 is ideal for tests CI. Or canary. For production, I don’t have any advice. There will be no 1.3.15.
They declared bankruptcy on the original code base so hard that they decided to chuck it all in the trash. I wouldn't hold my breath expecting support for their existing users.
Jarred, thank you for working on Bun. Many "vibe coded" :D projects start strong and are later abandoned (like potentially Anthropic C), so I understand why people worry about Bun's future. I hope Bun lasts for many years, like GCC. Bun is fast and great to use.
Anthropic's C compiler was a proof of concept[1], so it makes sense that it was abandoned.
[1] What it actually proved is up for debate.
I guess I'm debating, but it seemed clear enough to me? It proved that AI models and their harnesses are to the point where you can give them some work to do and leave them unattended for a long time, and they'll keep doing productive work for quite a while. This was a novel thing, and quite unclear, at the time the experiment was performed.
Obviously, the word "productive" is doing a lot of work there, but in my understanding the intention was nowhere near "commercially viable" or "practically useful", it was more like "not doing stupid shit like writing comments of the form 'This file contains the implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation ...'".
Maybe somewhere in the vicinity of "either passing more tests or generating more valid tests"?
The issue is that the Claude's C Compiler repository does not explicitly identify the project as a proof of concept. It was largely produced by one person directing Claude, and Bun's Rust rewrite also seems to have been driven by roughly one person using Claude Code. That similarity is what worries me. Bun's rewrite could also turn out to be proof of concept.
In Dutch there's a saying, "wij van wc eend adviseren wc eend", and it fits perfectly.
Frenchman here, I Google Translated that and it says
"We at WC Duck recommend WC Duck"... I'm left scratching my head, if you'd care to spell out what the saying means for non-Dutch I'd appreciate it :)
It was a commercial slogan for a toilet cleaning agent. An English equivalent would be "mr clean recommends you use mr clean". Today, it is used to point out when someone tells you they themselves delivered good work. Anytime you'd use the meme of Obama giving himself a medal, you could use this phrase.
The Toilet Duck brand exists in English. Canard-WC in French, even.
Actually the existence of the French name is confusing for English speakers as although many would know enough school French to get "canard" == "duck" if prompted, in English this word ends up meaning some sort of fabrication or hoax, apparently from an old French joke where somehow that punchline of that joke was popularized in England so long ago we don't have records. Human culture is weird.
So the first thing an English native might get from "Canard WC" is probably hoax toilet, I expect the duck imagery of the product would bring the "canard" == "duck" meaning across though.
I probably should have figured part of it out from my basic German, but I guess the Dutch don't capitalise nouns?
I don't see how it does. Claude Code is an extremely widely used product; the preceding comment offered an objective evaluation target, not a "trust me it's good" argument.
I don't see how Claude code being a widely used product is relevant to the person who orchestrated the Rust rewrite of bun saying that the orchestration of the Rust rewrite of bun went well. Wc eend is a widely used product as well, if that helps.
Ah, for context, which I suspect you may be unaware of, Jarred (the person who said the rewrite to rust went well) is the creator of bun, and the guy behind the rewrite.
I think the chain of reasoning is not hard to follow:
1. Assume the Rust rewrite of Bun went badly
2. Then something must be grievously wrong with a released bun runtime based on that code
3. Claude Code uses the released bun runtime based on that code
4. From #2 and #3, something must be grievously wrong with Claude Code
5. If something were grievously wrong with Claude Code, users would reduce use of Claude Code and use alternative tools
6. From #4 and #5, users are reducing use of Claude Code and using alternative tools
7. Claude Code has wide use and use is growing across all software engineering verticals
8. #6 and #7 contradict
9. From the contradiction, the assumption in #1 is false
The parts that are not explicitly spelled out here are an exercise for the reader. It doesn't really matter if the guy who wrote Bun said this or my uncle said this.
Ok, thanks for explaining! Doesn't really explain how the wc eend expression _doesn't_ apply here (which would be hard to do, because it _does_ apply, since this is someone praising their own work, and it doesn't get more straightforwardly applicable than that), but I do really appreciate the effort.
I always thought it was common sense and just basic critical thinking to take people paid by Anthropic praising products of Anthropic with a grain of salt (and let's be clear, that's what this is), but apparently it's not.
We would need to know at least:
- How many people have updated Claude/Bun to the latest version.
- How many subscribers care about reporting issues. Most of them are forced to use the tool against their will and have mentally checked out already. Why report issues if your employer values slop code anyway. Just log the hours and keep your head down. Maybe it is not expedient for the AI narrative to report issues!
- How many subscriptions are real vs. bulk distiller accounts.
- If subscriber numbers are inflated.
Judging by the weird Claude Code Github issues page, there are suspiciously few new issues: about 2 to 3 a day only vs. alleged subscriber numbers of 4 million.
By default, Claude Code updates itself all the time without asking for permission, so I'd say most users are on the latest versions.
I do not trust AI agents to run outside sandbox and use them only in dev container. I always use latest version available when I build container (once or twice a month). In my opinion it is to risky to allow auto update for SW which is released several times a week including weekends and is capable of/willing to do script kiddie pranks :-)
Well, OK, you do that. Many others don't. Not sure what your comment adds except saying "not everybody allows audo-update" which is IMO redundant and obvious.
That's not surprising. Claude code is buggy enough, and releases break things often enough, that I wouldn't expect users to distinguish bugs introduced by switching to rust-based-bun from the normal garden variety bugs.
I’ve come to just expect that my CC instance will randomly “blank” and that I have to resize my terminal / use page up/page down to get it to show again.
Supposedly they used a game engine to render their TUI but I’ve never had an FPS game do that.
They drive the TUI from the same thread that actual does stuff.. causing frequent freezes.
No GUI developer would ever put this on the same thread.
Just ask Claude to fix it, what’s the problem??????? /s
"Claude did implement multithreading in JS but we don't want to mantain a fork of WebKit" - jared apparently
I can count the number of times an @ file reference doesn't autocomplete on a hundred hands. Or how a rewind won't reset the "is this file Read" marker. Or how a Branch (forking a convo) takes literally 5+secs to run. Or how a slashcommand that's user-only will not work if its in the middle of a prompt. Or how ctrl-r search will match results that don't include any search terms. Or how you can't resume a branch given its session id.
Yes Boris, tell me more about how "coding is solved".
Edit: literally just now, while writing a claude code hook, opus5 gave me this LOC because apparently the changelog and what's in the transcripts _differs_; great docs d00ds.
Claude Code is quite buggy but doesn't generally crash, which is what you would expect if it shipped an immature backend for a month. Maybe the rewrite is full of bugs and they happened to result in the UI glitches or trashed settings files or whatever other application-level bugs that Claude Code has routinely rather than crashes but that would be pretty surprising.
Jarred thank you for doing the impossible over and over. Bun is such a fun thing to use after years of npm. Good luck with your quests! Have fun
If actually anyone noticed, then it is a pretty bad move. Also “going well overall “ does not answer the author’s observations either.
I noticed, I started getting memory leaks suddenly and it restarted the process in long sessions because of limitation of environment limit.
Ok, so you've just admitted that you have deployed thousands of lines of likely non-human reviewed LLM generated code (Bun's rust rewrite) to millions of client machines (via the Claude Code app auto-update) with significant local client access credentials, in a relatively quick and rushed manner.
What's stopping the LLM from having unscrupulously injected something nefarious into the codebase that you are unaware of?
What's stopping future updates from the LLM from doing the same?
Are you aware of the potential ramifications of deploying thousands of lines of non-human reviewed code to millions of users machines?
Are you happy to be personally responsible for the horrendous outcomes that could occur in these situations?
Claude Code has been written with Claude Code for a long time - that ship has long sailed.
Is that why Claude Code is buggy as hell?
Apparently it isn't good enough to generate native clients though, like many humans everything is Web tech.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I guess they put it in capitals for a reason.
"I put it in the terms of use, so I am not responsible for what my poorly developer software does" only goes so far.
It could be argued, probably successfully, that this is a case of gross negligence and that Anthropic should be held accountable for harm caused due to their reckless actions.
Especially now that they have been made aware of the possibility, they also cannot claim ignorance of the potential issues.
Certain consumer rights, depending upon the country, also cannot simply be removed or waived due to a organisation's terms of use or implied contract.
I would be stunned if there was a single line of hand written code in the entirety of Claude code lmao. Or if more than 20% of the code had been read by a person at any point. Why would you expect your ai code harness to not dogfood?
This article could increase its credibility by being updated to acknowledge that Bun-on-Rust has been live in Claude Code itself since June 17th, and available as a canary release since it landed on main.
Rewrites of this scale certainly justify long canary release periods!
I mention Anthropic dogfooding this in the article.
In this sentence, sure:
The problem is that your article's central claim is that there hasn't been a Bun release since the Rust rewrite - which can be read as implying that the rewrite hasn't been used in production.
But it's been used in production on millions of machines running Claude Code for over a month!
I think failing to acknowledge that hurts the credibility of the article. It's been a heated discussion point in this thread already.
I link to Jarred's writeup on bun.com, where you'll note he mentions that its being used on Prisma and Claude Code.
I don't agree that using something in a very specific environment is the same as a wide release.
I trust readers will either know the backstory or read the articles I link to. Such is life if they don't.
Why are you resistant to adding a sentence to the article that notes that Claude Code uses the rewrite?
Do you think it would weaken the article?
When I said it would improve the credibility I did mean it. My instinct on reading the article this morning was "this person doesn't know that Claude Code runs on Bun, which weakens their credibility in presenting the argument they are making here."
Please feel free to write an article that corrects my mistakes.
I try not to publish articles that call out mistakes by other people just for the sake of it. I've written a fair amount about the Bun rewrite already - https://simonwillison.net/search/?q=bun%20rust
You've got my blessing. I think given how mistaken I am, it should be quite an engaging article.
To me this seems like an odd preoccupation for an article that is very little about the Bun rewrite as a running program and very much about the process of the re-write and how it came to be in commits to the repository.
You could argue that the release tag isn't important - but at the top of this comment thread a member of the team confirms they delayed the release to finish some extra testing. So the ambiguity around if the project is complete and pointing to the lack of a release mirrors internal sentiment as well.
Author here: Exactly.
I had a funny thought that Bun might add a release tag while I was still writing the article. In that case I'd still publish it, because the point is we still don't know the cost it took to get to a viable, wide, release. The $165k isn't the full story.
It's not your article, bud. They have already addressed your concerns, and don't need to make changes just because you feel the article isn't "fair".
And your instinct was clearly mistaken. You should read the article more carefully before offering criticism.
I stand by what I said. I was offering honest advice: when I read the article I thought exactly that, and so did other people based on the comments in this thread - which I think shows my instinct has value here.
There's an easy fix. If they don't want to take my advice that's completely fine.
Well it hasn't. "Production" for a language runtime means being generally available for arbitrary use. The engineers that built the runtime using it to release one closed source binary to the public is, at best, an extremely narrow beta test.
It's available for arbitrary use if you run the canary release.
In no world does "New iOS released" mean "there's a developer preview" which is what you're proposing.
One metric I thought might be interesting with respect to the Rust rewrite is the number of "unsafe" occurrences in the code.
I was optimistic those would be going down over time but it looks like they've stayed pretty constant: https://news.ycombinator.com/item?id=48966569#48967630
Does that data exclude FFI wrappers, which necessarily must be unsafe? If not, don’t put much stock in it.
No, it's a raw count.
I get that there's a baseline of unsafe that's necessary, but I was under the impression that some of those unsafes were in places where they could be replaced by more idiomatic Rust at a later date.
I don't think that's true. I think a fair chunk of them are places where Bun is handed a pointer by WebKit or something similar. I believe they write about this a little.
I think there's a reasonable expectation that unsafe could still be reduced by having shared, safer abstractions - that would lead to fewer `unsafe` results because the `unsafe` would be contained. I'm surprised that this isn't a higher priority target for them.
The bun rewrite inspired me to be much more aggressive on porting code, rewriting code, or vendoring external dependencies to tailor them specifically to our needs in ways that doesn’t make sense to upstream.
I feel like it made me generally more ambitious in what I’d throw at a coding model, but also made me focus a lot more on our testing harness and keeping a lot of it at the boundaries outside the language specific parts.
Having been part of several huge rewrites before, some multi-year long, I definitely would consider bun’s rewrite an enormous success. To keep such a level of test and feature parity, and add improvements on top of it, is a massive engineering feat.
As a comparison point, someone decided to try to fix the issues in the Zig original and is now claiming sub-second build times, plus fixed bugs, by modernizing the codebase and sticking with best practices - indicating that all of the issues that justified the rewrite were self-inflicted and addressable.
https://ziggit.dev/t/buz-a-drop-in-replacement-for-bun-using...
I have no skin in this game, and the Zig version is also using LLMs if that helps take the culture war out of it. But, it has always been true in my experience that someone who really understands a problem space can outcompete someone who just throws resources (in hundreds of thousands of dollars of token spend) at it.
The main issue that justified the rewrite were memory bugs, especially related to interaction with GC managed Javascript objects. There is no fully general way to prevent those bugs in Zig, and I don't see any claims that they did so in Buz.
They also complained about build times, and in fact the Rust rewrite started immediately after some other drama about Bun being unable to contribute back LLM-written changes to the Zig compiler to improve build times, and the Zig team rejecting them in principle. So while memory issues did become the focus later, I don't think it was the entire story.
Migrating to Rust in a one-to-one translation with unsafe blocks does not make the code any more safe initially. It might provide tools to do a significant refactor that solves lifetime issues with Rust's help, but I haven't seen evidence that they've done that either. They're also embedding a large C++ codebase, JavaScriptCore, so there are always going to be unsafe areas and touchpoints where memory issues could live, and Rust won't magically solve them.
It wasn’t just on principle that those changes were rejected, they also stated the bun changes were not actually that great or general enough to upstream.
This looks like a meme or attempt at a joke.
They're refusing to accept human-authored contributions. They're using LLMs to do the work. The author says they'll use LLMs to de-slop what they think is slop, and humans are banned from contributing.
I don't think you should take this seriously.
Rust devs are so obsessed with writing things in Rust that Rust was re-written in Rust.
Self-hosting a language used to be standard practice. These days that's become a bit more controversial, but I definitely wouldn't lump that in as a sign of obsession.
At what point should I trust projects like this?
I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code. So I'm not sure I trust it just because tests pass. I also think that tests do not and cannot check everything.
I also don't trust it just because it compiles in Rust. The Rust compiler does not check everything.
So at what point do projects like this cross from "untrusted" to "trusted"?
That's very easy to prevent. Don't let them edit the tests! Run the test suite against a reserved copy.
That makes sense to me as a tactic to prevent that problem.
But the article talks about how so much code was written so fast. Seems to me that to create that much code that fast you have to have AI produce both the code and the tests.
So I am not sure in this project if the AI can edit the tests or not. I assume that because this is Anthropic the AI is doing as much as possible, which would include editing tests.
Bun had an enormous existing test suite written in TypeScript. Getting those tests to pass against the Rust version was the key thing that enabled the project.
You can go and check if the AI edited the tests yourself: look at the git history of those files in the public Bun repository.
But Bun also implements the interpreter to those tests— doesn't that mean it has a lot of leeway to over-fit to them? It's not as clean as "don't change these files" in this case.
In general I would agree though, and would take it one step further: the agent writing the source code should not even be able to see the tests, nor the agent writing the tests see the source code.
There's probably a ton of intangible factors to this, but how do you measure the ROI on this?
The Rust compiler suffers from a number of crash bugs and nondeterminism, and they won't accept AI diagnoses or fixes, so Rust has become an unreliable partner for software development.
If you're going to do serious development with Rust, I suggest forking the compiler. Upstream your fixes to a fork which takes AI contributions, or fork your own. Or keep all of your improvements private, that works just fine.
I don't quite understand the focus on the token cost of this rewrite. Obviously, we should examine if this rewrite is good, effective, good for the product etc., but the token cost seems ... not important?
The marketing value of this to Anthropic (if Anthropic even cares, this might just be the Bun team selling past the close) is to show that such a rewrite is possible and delivers engineering value. If exactly this project is $800K today, it'll be $200K and then $80K soon, so it's not so important to the story that it's cheap, just that a big "cool" rewrite is possible, and delivers velocity to the buisness.
I'd say it's an important data point if you'd want to do something similar yourself.
It isn't clear to me that the price is worth it.
I think, we all are phrasing this wrong. Bun was <strike>rewritten</strike> retooled in Rust by AI with only ensuring integration tests and usage tests succeed. That's similar how to a C program was compiled to binary or Typescript was transpiled to Javascript and run. We didn't make a very big deal of it then, and I think, we should see this operation as a similar higher level source to source translation, which machines have been doing.
Writing code is a different thing.
Transpiling and a LLM hallucinating some code that _somehow_ passes the tests is not really the same thing though.
I just got a github notification on an old Bun bug report when it was still coded in zig. The bun-bot had completely solved the bug in the new rust codebase, added comprehensive tests, did the write up, pushed the commit all without human interaction. The fix looked sound and changed minimal lines of code. This AI is the real deal. Programmers should be concerned.
Jarvis, farm me some hn karma
This doesn't answer the question it asks.
I do believe they were trying to use CodeRabbit to review their re-written code. https://www.coderabbit.ai/blog/ai-can-migrate-your-entire-co...
I've "seen enough" by now
Any runtime written in a compiled language gets translated to completely different language in seconds every time it is built! That is what should already terrify you. :)
I can see CI battling pretty hard with rusts slow compile times but not sure that is particularly conclusive of anything when it comes to the success of the rewrite
Jarred from Bun is in this comment section saying the rewrite isn't finished yet. I therefore don't consider it a failure or a success. I'll be keen to see how much the CI cost though since that's a part of the cost of the rewrite.