And like, this is just the beginning of the port. They did a mechanical port basically line by line, next step is to make it idiomatic rust.
I thought by now people would’ve learned to stop betting against this rewrite.
As with all transpile ports, the true test will be how well it can be extended and maintained over time. Historically working with the output of a transpile is not pleasant and requires heavy rework to get it to the point where you can be comfortable enough to extend it.
The existing community is now either going to need to learn Rust or new Rust developers are going to have to join the project and they may not invested enough to refactor the transpiled output when they could work on something else like Boa.
This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.
I'm not quite as optimistic. "Unpleasantness" might sound like subjective disgust, but it often relates to objective criteria like complexity, that increases the surface area open to bugs in a real way. Similarly, if reworking has a non-0 chance of bugs, its gonna have some form of risk, and a major one will of course be higher.
LLMs may be capable of a lot, and they miggt change what projects people can take on, but they definitely don't write bug free code.
The bun rewrite/transpile did use some neat ideas like lots of testing and per-file translations, so hopefully they have more in their toolbox than "LLMs hopefully won't be affected by complexity or write bugs"
You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.
Given the success of the port so far and the fact that CC is now running on rust Bun, that seems highly unlikely to me.
I'd also like to inform you that
- the current success metrics solely consist of their advertisement, my eyes looking at the code strongly suggest otherwise
- the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust and relying on model knowledge is already proven insufficient.
The release decision itself is presumably driven by that tbh. It's only LGTM from there when nobody knows how to review unsafe Rust.
Do you know how silly this sounds? Good engineers can work in any language. At the top companies (of which Anthropic is certainly one) they don’t have “C++ engineers” and “rust engineers” they just have engineers.
Given that they are investing their time into actually learning the language before diving into this mess. No, unsafe Rust isn't supposed to be something you can handle without prior knowledge.
Jarred was even asking in public how to use traits without runtime overhead during the rewrite. And the blog post phrased it like a normal problem to encounter while doing a million lines port... That's two months after the initial rewrite so you can guess if they learned.
They were up and running and super-productive with Django within a week.
It would have made far more sense, for reliability, efficiency, cost, etc., every metric really, to use or write a source to source translator that preserves as much structure from the original code as possible. Typically if you do a rewrite there are lessons learned from the existing code base that you want to take into account when doing the rewrite; using a bunch of agents to do the porting file-by-file buys you none of that. In either case the code will be an unidiomatic translation, just with LLMs you get an added source of indeterminism and a huge bill at the end of the month.
Is all you need to know to consider how much of an abomination it is
2026-05-14 23427db 13907
2026-05-14 19d8ade 13861
2026-05-15 4d443e5 13840
2026-05-17 172afa5 13803
2026-05-17 80a06a8 13849
2026-05-18 fba43af 14026
2026-05-19 303cd28 14052
2026-05-20 21db682 14243
2026-05-22 a06a00a 14239
2026-05-23 49c97de 14090
2026-05-28 472a06a 14076
2026-06-01 a0d1472 14071
2026-06-04 8553428 14032
2026-06-09 717542f 14053
2026-06-10 1c90e5a 14043
2026-06-11 6e91d24 14031
2026-06-16 bd8edc7 14086
2026-06-17 6ef5977 14104
2026-06-20 315ed50 14106
2026-06-22 c6be834 14120
2026-06-23 ea7e44f 14108
2026-06-23 03042ab 14128
2026-06-29 86d32c8 14046
2026-07-01 6640fcf 14077
2026-07-04 51074e3 14099
2026-07-06 9d0e93d 14186
2026-07-08 ab6eb2d 13953
2026-07-09 86caf6e 13936
2026-07-10 91675d0 13930
2026-07-13 73b6c14 13951
2026-07-16 4bbe075 13978
2026-07-16 57e30a5 13995
ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...
Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence.
All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?
True.
> has fewer bugs
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that:
The second that you start to introduce nonsensical axioms (or bugs in unsafe sections) all your proven correct theorems will be worthless.
It’ll most likely still do 99% of the things people need it to do, there’ll be a an issue created for that broken 1%, and eventually it’ll be iterated upon and fixed.
Unless you’re working on a security boundary of course, there you should treat it like maths.
bad axiom -> worthless theorem.
bad unsafe section -> verified safe section is actually not safe.
The proof that there are no (for rust's definition of "no") memory bugs becomes worthless, not the entire software itself.
Maybe? I'm not sure.
> The proof that there are no (for rust's definition of "no") memory bugs becomes worthless
I still don't think so, the proof that there are no memory bugs is definitely not worthless, since while the whole proof itself is binary (it is either fully correct or not), its effects act more like coverage, and the more of it that happens to be partially correct, the better.
I think cve-rs is the perfect example of this. Its very existence proves that the borrow checker is already unsound, and with that, the very foundations of Rust's safety guarantees are currently flawed.
TypeScript is another good example, its type system has been repeatedly proven to be unsound, so it's also flawed.
But so what if it's flawed? Many smaller properties of these proofs still happen to hold, and they might prevent 90%+ of CVEs even as flawed as they are.
I'm not sure I'm following what you're saying here. In the rewrite blog post it has been stated that the Rust port landed in a place where it passes 100% of the existing test suite and does so without some of the known memory leaks of the Zig version that they were aware of and didn't know how to address.
Sure, there's no guarantee that the port didn't introduce new bugs and most likely it did, but the 1.4 version has not been released yet, so I don't think a direct comparison of a long-time "stable" version and the just-landed full rewrite is meaningfully helpful.
> "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
But that just means that once you get rid of the unsafe block, you're pretty much guaranteed by the Rust compiler to be memory-safe. This means that all your potential memory landmines are annotated in the code and once you disarm them all, you're memory-safe.
I don't understand how what you're saying contradicts any of my statements.
> Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out.
Still easier than the Zig version, where all the same things you've mentioned apply, but also there's no visible indication of progress and issues are unmarked and could be pretty much anywhere.
> It's too early to declare it as anything remotely close to a win, optimistically saying.
Based on the rewrite blog post it's pretty clear that the Rust version is outperforming the Zig version by pretty much every measurable metric at this point.
I think the backlash is mostly focused on the ideological opposition to fully AI-authored 1MLOC+ PR approach they took.
They can't mention what they don't know. And that's the exact reason I'm against this: doing a port without being able to tell what is correct is asking for a disaster, obviously.
I've checked their posts and blogs for a few times, and I'm quite sure they don't know any of these to write about them.
> the 1.4 version has not been released yet
Let's hope the repeated delays (it was scheduled for last week) are not for quality issues, otherwise I'll only be half correct. It appears that all the MIRI errors are not stopping them though. (They have a script to run it but most probably it just fails and they don't care. Personally I'm not executing any of bun's code to avoid summoning nasal demons, so I actually don't know for sure)
> get rid of the unsafe block
Would be possible if they are not disregarding everything else going for numbers. E.g. they are actively increasing the unsafe surface by rewriting some code in SIMD C++ (https://github.com/oven-sh/bun/pull/33032). As if no Rust solutions already exist.
> Still easier than the Zig version
Well, this is true but only realizable if they know how to deal with the new problems emerging during the process. My current conclusion is that they don't.
> ideological
For me it's methodological as explained above.
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)