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).
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.
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.
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.
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.
> 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.
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 otherwise Microsoft wouldn't keep them.
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.
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).
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.
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.
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.
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.
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.
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.
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 like just break some discrete part.
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.
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.
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.
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).
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.
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'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).
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"
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.
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 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'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.
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 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.
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.
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.
I think they're taking things "gradually" as they are under a lot of scrutiny and no rush for full release.
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.
(also, fwiw, a manual rewrite would be under the same scrunity and suffer from the same skepticism, at least when obviously rushed).
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 ...
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.
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.
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.
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 otherwise Microsoft wouldn't keep them.
And .doc files are basically a memory dump.
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.
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.
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.
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.
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.
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.
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.
That’s peanuts, if not the shells of the peanuts, for a project and company of this magnitude
- 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
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.
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.
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.
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 like just break some discrete part.
Hence, the author concludes that rust rewrite is not complete as bun in rust is not released yet.
I agree with author's POV.
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.
Perhaps. But were that the case, one would think they'd be quite eager to say so.
Are you expecting them to live-tweet their work or something?
why shouldnt upcoming work be as public as the rewrite itself was?
I use more (albeit cached) when centering a div.
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?
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).
How odd. Lot of mental gymnastics going on there.
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.
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).
What a time to be alive
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
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.
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.
Thankfully now I have some good material to post-rationalise my intuitive dislike
I shouldn't be surprised though, of course. Giving any credit or slack to a high-valuation LLM company is a silly endeavor.
You and me both friend!