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.
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.
> 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'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.
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 successfully 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.
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!
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. 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 that is not very intertwined, TypeScript is a much larger project both in LOC and in complexity.
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 confidende in the Rust 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"
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.
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.
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 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.
While the Rust rewrite branch might not be officially released, Anthropic and (I assume) the Bun team considered it good enough to ship to millions of Claude Code users (since v2.1.181) for over a month now!
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.
They also have made a release, in a sense, since they moved all Claude code users to it. (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.
I've had several bun-related crashes in Claude code in the last week, which I don't remember ever seeing before then.
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.
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.
What have we become ...
> 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.
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.
I think they might mean Word as in Microsoft Word. Just based on the feature list they were describing.
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.
>Word is basically an operating system.
And .doc files are basically a memory dump.
Haha, I misread as "word games" and was very confused about the claim.
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.
Maybe it would have made more sense for Anthropic to rewrite Claude Code in rust, and cut out the middle man (bun)?
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'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.
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.
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 successfully 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.
Just a couple more 100hr weeks of debugging, and the last 80% will be done :-)
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!
the author wrote a whole blog post asking how the bun rewrite is going and the answer from the thread is: nobody knows, including the author
That's absolutely correct!
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.
> This post doesn’t make sense
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. 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 that is not very intertwined, TypeScript is a much larger project both in LOC and in complexity.
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”.
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.
How much of the Bun/Node API surface does Claude Code actually use though? Conceptually it's a relatively simple TUI application.
I think they meant “released and available for use” rather than just out in the wild.
It is available for use: `bun upgrade --canary`
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.
> 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?
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.
They also would have produced a team of engineers that knows the Rust codebase.
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
This is where we've come to where people proudly proclaim using an AI to do what is a single line of CSS.
100k tokens is your pre-prompt and your CLAUDE.md as well as a few files from your root.
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 doubt file by file rewriting takes as much work as rewriting and refactoring the code - especially at this scale.
> produced idiomatic rust
I keep seeing this. What is "un-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.
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.
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 confidende in the Rust 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"
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?
To me it just looks like a marketing stunt.
> _"...Canny..."_
What a time to be alive
Still have no idea what that means…
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!!!
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.
> and being used in a massive product already?
One single product, AFAIK, and one ladden with bugs and issue too.
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.
Hope you find that job :) nice work experience, looks very ethical focused.
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.
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 am none the wiser about how it's going.
You and me both friend!
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.
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.
While the Rust rewrite branch might not be officially released, Anthropic and (I assume) the Bun team considered it good enough to ship to millions of Claude Code users (since v2.1.181) for over a month now!