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.
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.
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).
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.
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.
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.
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 use for you're toy projects.
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.
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.
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.
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.
> 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.
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.
> 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 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.
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.
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.
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).
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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).
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"
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.
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.
> 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.
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.
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
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.
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.
Coincidentally - I'm trying to get feedback on my own rewrite project - MAME ROM machine code to Idiomatic JavaScript - but sadly HN is hiding my post... :(
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 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.
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'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 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.
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.
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).
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 :)
Is it though? What’s your source for that data?
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.
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.
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.
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 use for you're toy projects.
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.
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 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.
> (now legend) Terry bothering us to check out LoseThos or GodOS or whatever was its name
Temple OS :)
Dude was a tweaker xD
> 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.
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.
> 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.
> 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.
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.
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.
> 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 are used, otherwise Microsoft wouldn't keep them around.
>Word is basically an operating system.
And .doc files are basically a memory dump.
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
Dump is a great word for it
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.
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.
> Using a LLM to translate a project in a short time, is by itself incredible.
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.)
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.
>because one is tired of typing
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).
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.
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.
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 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.
Anyone know why? Can’t CC run on any JS runtime?
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.
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.
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.
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.
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.
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.
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.
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.
"centering div" is a classic problem (/trauma/meme) that sounds trivial but had no universal solution (until 2017?).
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).
> 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).
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.
> "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?'
that is indeed a roughly accurate definition of what "unidiomatic" means
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.
> 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'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"
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.
> I hadn’t seen the numbers for the CI/CD costs of Buildkite, and as you might have noticed from above, some PRs were written by Anthropic employees.
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.
> some PRs were written by Anthropic employees
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...
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 (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.
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.
I think they meant “released and available for use” rather than just out in the wild.
It is available for use: `bun upgrade --canary`
How much of the Bun/Node API surface does Claude Code actually use though? Conceptually it's a relatively simple TUI application.
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.
> 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.
> 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?
Based on the way they live-tweeted (as it were) their rewrite and their other publicity stunts? Yes, actually.
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.
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.
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
Came to point this out as well. Very bizarre that it was capitalized. Italics or bold might even have been acceptable...
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
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.
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!
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
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.
Coincidentally - I'm trying to get feedback on my own rewrite project - MAME ROM machine code to Idiomatic JavaScript - but sadly HN is hiding my post... :(
https://news.ycombinator.com/item?id=49069383
EDIT: I'd love to hear why I'm downvoted.
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.
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.
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.
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
"Nobody knows" is not a neutral sign however, Anthropic should be able to provide that visibility
That's absolutely correct!
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!
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.
> we’re approaching $800k in money spent on this rewrite.
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
Ohhhhh for a world where that's peanuts for an open source project.