That's not surprising. Claude code is buggy enough, and releases break things often enough, that I wouldn't expect users to distinguish bugs introduced by switching to rust-based-bun from the normal garden variety bugs.

Take as long as you need to ensure software quality. A month without a release isn't a big deal and whomever needs a specific feature can offer to contribute or build themselves.

Node has 4-6 weeks without a meaningful release (other than security stuff) pretty much every December. I think the criticism in the article is unfounded and whomever needed/wanted a release should have asked first instead of writing an "angry" blog post.

(I'm a Node.js maintainer)

I’m really glad I don’t use anything that relies on Bun. What a mess you’ve made of this whole thing.

Jarred thank you for doing the impossible over and over. Bun is such a fun thing to use after years of npm. Good luck with your quests! Have fun

If actually anyone noticed, then it is a pretty bad move. Also “going well overall “ does not answer the author’s observations either.

Any comment on the costs estimated in the article? especially the buildkite costs?

Jarred, thank you for working on Bun. Many "vibe coded" :D projects start strong and are later abandoned (like potentially Anthropic C), so I understand why people worry about Bun's future. I hope Bun lasts for many years, like GCC. Bun is fast and great to use.

Any chance for 1.3.15 with bugfixes for the rest of us?

In Dutch there's a saying, "wij van wc eend adviseren wc eend", and it fits perfectly.

> The Rust rewrite is going well overall.

I look forward to the postmortem!

We would need to know at least:

- How many people have updated Claude/Bun to the latest version.

- How many subscribers care about reporting issues. Most of them are forced to use the tool against their will and have mentally checked out already. Why report issues if your employer values slop code anyway. Just log the hours and keep your head down. Maybe it is not expedient for the AI narrative to report issues!

- How many subscriptions are real vs. bulk distiller accounts.

- If subscriber numbers are inflated.

Judging by the weird Claude Code Github issues page, there are suspiciously few new issues: about 2 to 3 a day only vs. alleged subscriber numbers of 4 million.

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.

The CI/CD costs are an interesting take, most of the rebuttals to AI ROI are something like “more code doesn’t mean more value!” but if you are charging per CI run then it actually does! Particularly with CI and extra testing being the main way to prevent the loops the AI companies are shilling from going off the rails

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.

I'd like more people to be writing about this, because I find it fascinating. I have my own private project that is heavily LLM-coded, just to learn about what it's like. It's amazing how everything is different yet everything is the same. Big complicated features can start working quickly and give a massive endorphin boost, but then fixing them up and integrating them in properly and polishing the UI? It all feels even more painful having experienced the heady thrill of the initial implementation. And things get to a point where you can feel the inertia set in, the point where things have gotten so hacked up that the LLM can't make any progress without creating an even bigger mess. It's the point where you have to go back and fix up the architecture, or scrap the whole thing and restart with a better plan, or a bit of both (rewind to the "last sane point"). It's like developing with a jetpack -- you can go way faster towards your goal, and you can slam into walls way faster and more painfully too.

I think there are tons of learnings to be shared about how to do this stuff, but it seems like it's all blocked behind arguments over whether AI is the best or worst thing ever, and penis-measuring contents about how to hold the tool. The net benefit is a very open question, and both the doom and gloom perspective and the AI booster perspective are valuable and have a lot of things right. But there's a dearth of information about what things work, what things don't, what happens in the process of using AI, how to adjust one's behavior and which of those adjustments is harmful even if effective.

But then, I'm part of the problem. I keep meaning to write up a series of experience reports, but it's a lot of work. More fun to vibe a new feature into existence, or to finally fix a UI wart...

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.

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.

> Not understanding to the core the software you wrote, is going to exploded in your face.

Short-termism at its peak. Code maintainers will learn the hard way how to set the boundaries between ai-generated code, and human maintainable code.

> I 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.

> 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.

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).

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.)

> indicating that all of the issues that justified the rewrite were self-inflicted and addressable

The main issue that justified the rewrite were memory bugs, especially related to interaction with GC managed Javascript objects. There is no fully general way to prevent those bugs in Zig, and I don't see any claims that they did so in Buz.

This looks like a meme or attempt at a joke.

> Bun is the quintessential AI slop project at this point. Inheriting that is no easy task. I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape. It will likely require most subsystems to be rewritten.

They're refusing to accept human-authored contributions. They're using LLMs to do the work. The author says they'll use LLMs to de-slop what they think is slop, and humans are banned from contributing.

I don't think you should take this seriously.

[dead]

>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.

> experienced devs

No one on their team had Rust experience

You see this response because the port of Bun from Zig to Rust does not have anything to teach us about Zig, Rust or porting between languages with LLMs.

There are so many non-quantifiable properties to evaluate of the 'before' and 'after' codebases. Choices and preferences to be had about languages, language porting in general, and LLM coding.

After all that, pretend we could have a clear convincing distillation of the port and want to go apply the lessons learned. If someone doesn't get LLM porting results as good as Bun did, or it cost them substantially more in tokens, then they're "holding it wrong." If someone is underwhelmed by Bun's results, then it was just a proof of concept and the models have gotten so much better in the last 6 months anyway you can't compare.

> so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that

There's a laundry list of reasons to be skeptical about LLM results in general. The biggest one is that LLMs are excellent at creating output that looks right but is nevertheless still wrong.

In this particular case, there's also a specific reason: This is obviously a marketing stunt regardless of whether the claimed results hold up. Anthropic has a long history of just lying and making shit up, so any results are subject to extra scrutiny.

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.

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.

Why wouldn't they?

Bun is a major part of the web ecosystem, having it developed by them via AI, sounds like a gigantic pr win.

Anyone know why? Can’t CC run on any JS runtime?

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.

I mention Anthropic dogfooding this in the article.

> the team of engineers would have produced idiomatic rust

Not necessarily. Didn’t Microsoft port the TS compiler to Go and they did it by translating the TS? It wasn’t idiomatic Go.

They also would have produced a team of engineers that knows the Rust codebase.

Yes, and curiously many of the tellings of this story don't account for the costs of the human software engineers (Jarred and the other bun team members) who guided all of this work.

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.

Would they have, in a year? The general plan of attack would likely still be the same: rewrite it in rust while keeping the structure as similar as possible, no matter how unidiomatic, then adjusting the design to make it more idiomatic to rust. Doing both at once is much harder.

IMO a team of engineers (presuming this is pre-AI) would have improved the existing Zig codebase, rather than spent time and money on a Rust port in the first place. In fact, I still think most teams of engineers would choose to improve what they have even now, circa AI.

I doubt file by file rewriting takes as much work as rewriting and refactoring the code - especially at this scale.

Yes this is a typical case of showing results fast. I wonder what the cost for the remaining 10℅ of debugging and fixing all the bloat will be. Not so cheap I am guessing

> produced idiomatic rust

I keep seeing this. What is "un-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.

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.

Transpiling and a LLM hallucinating some code that _somehow_ passes the tests is not really the same thing though.

I'd say it's an important data point if you'd want to do something similar yourself.

> 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

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.

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.

> 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.

> 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.

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.

> I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code.

That's very easy to prevent. Don't let them edit the tests! Run the test suite against a reserved copy.

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.

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.

Does that data exclude FFI wrappers, which necessarily must be unsafe? If not, don’t put much stock in it.

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...

Still have no idea what that means…

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.

They bought the maintainers, not the code.

To me it just looks like a marketing stunt.

It was expected. These LLM rewrites seem to work amazingly at first and then you realize there is a ton of work remaining.

Hope you find that job :) nice work experience, looks very ethical focused.

what kind of difference from the actual numbers does it result in?

"Nobody knows" is not a neutral sign however, Anthropic should be able to provide that visibility

That's absolutely correct!

> I am none the wiser about how it's going.

You and me both friend!

It's pretty off topic/ irrelevant and it's self promotion.

Self-hosting a language used to be standard practice. These days that's become a bit more controversial, but I definitely wouldn't lump that in as a sign of obsession.

Yeah, the answer is that it's gonna working fine for most users.

How does that help 99.9% of all other companies though?

Ohhhhh for a world where that's peanuts for an open source project.