I was first interested in Bun because it was written in Zig. I was interested in Zig because I respected Andrew Kelley's decision-making, and his taste matched my own.
I got really excited about Bun for many reasons after that, but they essentially came down to a similar root: the decisions were ones that I respected and would probably have made myself if I had thought of them.
I was a little concerned when Bun was acquired by Anthropic, but forced myself to remain cautiously optimistic.
This behavior, though, is exactly the sort of decision-making that I don't respect. I've got nothing against Rust, but if this is how Anthropic is managing Bun, I can no longer bet on it being a reliable part of my toolkit. It isn't just the code, it's the thought behind it that I have to trust.
I was so excited by Bun for many of the use-cases I have, but this just turns me off completely. This looks like an Anthropic internal-only tool, based on the behavior.
I don't have a single reason not to pick nodejs when doing JS.
But, I warmed up to Bun over the last couple years almost against my own will — trying to maintain a pretty large body of TypeScript code in a runtime-agnostic way (including even Node, since 24.2). I don't want to make any specific TypeScript runtime a requirement for my TypeScript code, unless there are really good reasons to do so.
But Bun (like Deno) kept providing those reasons. Postgres, SQLite, S3, websockets, local secrets (Keychain/wallet), bundling, compilation, killer speed. So I (somewhat grudgingly) started using Bun more, and even made it a requirement for some of my projects (albeit, in ways I could walk back later if needed).
Today, I have a bunch of API servers and frontend app servers which are bun build --compile --bytecode single executables ,that can run and be deployed virtually anywhere.
I've been very happy with it so far. But also, I don’t think that the way I am doing it is super-common, and now that they are doing this, uh... extremely ambitious LLM port, I am perfectly positioned to regret all of my decisions around Bun if this port ends up sucking.
So I'm a little nervous, but... what if it doesn't suck? That would be cool, because a.) they will have shown something interesting about what is possible with LLMs (albeit if you are rounds-to-a-trillion-dollars valuation frontier AI lab, lol, but still). And b.) going forward, Bun will be developed in Rust. We all have our own preferences, obviously, but to me, that's a win.
And if it does suck, though — that's super interesting too! Will be annoying to me to re-architect my Bun-specific shit to Deno, but for the world at large (and me, too) that's still interesting information!
Because Bun is perfectly positioned to do a huge LLM-powered port. They are one of the premier TS/JS runtimes, it's obviously and insane marketing pillar for the AI lab that bought them, they have unfathomable resources and access to the cutting-edge models that all of us don't get to play with yet, and for all intents and purposes, they have unlimited money to do this.
So if they can't do it — which will be really obvious, I think, if true — then it really just isn't possible yet, and all the naysayers were right.
I don't know, I've followed Deno, and it appeared to me an incredibly low ambition from the get go.
What I was specifically referring to is Deno (originally) trying to fix the (glaring, fundamental) problems that Node imposes on the world, vs just do them faster.
Why not both? How about that: perfectly fine for Anthropic but suck for everyone else.
but sure anthropic might not agree
However, I think if it turns out that that's the case, then their port will fail in two ways (to paraphrase Hemingway): gradually, and then suddenly.
I don't think this port can be a success unless they end up — on the other side of it, not necessarily immediately — with maintainable Rust code.
When we've seen linux having a new significant exploit every other day now thanks to LLMs being better at weaponizing memory bugs this seems significant.
But yes, URL imports have a variety of other issues (duplicated dependencies, no resource integrity), though Deno solved them in later versions (npm registry support, lock files).
The only benefit of Deno is its permissions system, which has been great for safely letting agents write and run scripts on my file system.
This is optional, but also really, really handy for standalone scripts that don't need to come with a package-lock.json or deno.lock file (if you're not aware, Deno did a lot of changes to package management in later versions).
In this case, I would trust the output even less than the input. The input was memory-unsafe but hand-written. The output is memory-unsafe but also vibe-coded and has had no eyeballs on it. What is the point of abusing agentic AI for this use-case?
Have you ever seen what comes out of c2rust? It's awful. It relies on a library of functions which emulate unsafe C pointer semantics with unsafe Rust.
A few years ago, when I was struggling with bugs in OpenJPEG (a JPEG 2000 decoder), someone tried running it through c2rust. The converted unsafe rust segfaulted at the same place the C code did. It's compatible, but not safe.
Main insight: don't do string manipulation in C or unsafe Rust. It's totally the wrong tool for the job.
This doesn’t work like you think it does. These things are full of errors and make the code very verbose and hard to reason about. It works with small apps, not entire rewrites.
AI disproportionately empowers the stupid and evil
The issue isn't the existence of undefined behavior that miri would catch. The issue is exposing an API that allows undefined behavior from safe code - which miri only catches if you go write the test that proves it.
This isn't an all together unreasonable thing to happen during an initial port of code from an unsafe language. You can, and the bun team seems to be, go around later and make sure that the functions where you wrap unsafe code does so correctly. Temporarily in a porting stage incorrectly marking some unsafe functions as safe isn't a real issue. It's a bit strange to merge it into the main repo in this state, but not a wholly unreasonable thing to do if the team has decided that they're definitely doing this. The only real issue would be if they made an actual release with the code in this state.
It's also a bit unfortunate that they didn't immediately set up their tests to run in miri if only because LLMs respond so well to good tests - I know they didn't do this not because of this github issue (which doesn't demonstrate that) but because there's another test [1] that absolutely does invoke undefined behavior that miri would catch. Though the code it's testing doesn't actually appear to be used anywhere so it's not much of a real issue. That said it's obviously early in the porting process... maybe they'll get around to it (or just get rid of all this unsafe code that they don't actually need).
[1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - the pointers derived from the first mutable references are invalidated by creating a new mutable reference to the same object. In C terms think of "mutable reference" as "restrict reference which a trivial mutation is made through". It's easy to do this properly, derive all the pointers from the same mutable reference, it just wasn't done properly.
PS. Spamming github just makes people less likely to work in the open. Please don't. We can all judge this work just fine on third party sites.
PPS. And we might want to withhold judgement until it's in a published state. Judging intermediate working states doesn't seem terribly fair or interesting to me.
If you are making a full rewrite and have non-working, in-progress code, you use a branch. This way you can still have the working "main", in case there is a security fix needed or something.
Couldn't a case be made that it's better to get Bun to the to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as a follow-on effort? It seems preferable to requiring perfection on the very first step.
What is a bit disappointing is that the Rust code apparently has APIs that aren't marked unsafe but may cause UB anyway. When doing this kind of translation, I'd always err on the side of caution and start by marking all/most things unsafe. Or prompt the slopbots to do the same I guess.
Then you can go in and verify the safety of individual bits step by step.
The bar for matching tsc's behavior is really _really_ high. see:
https://github.com/type-challenges/type-challenges
I'm not against using LLMs to write a lot of code. But verification should be 100x more robust now that we can output code at this rate.
- Test before code, Bun had lots of test so that's good but maybe they could start by asking Mythos to write like 20k additional tests that pass on Zig Bun first.
- Deterministic anti-slop features. LLMs love to solve the problem in the wrong abstraction layer or place. There are many ways to catch this with deterministic tests. I do this in tsz a lot
- Roadmap that constantly evolving by humans.
- Taking a pause and looking how the progress is going and undoing slop
- Fuzztest(https://github.com/google/fuzztest) style "trying to break things" with the powers of LLM
This asymmetry is well understood by marketing and PR professionals, and actively exploited.
Did they even claim it was "memory-safe"? Every discussion of this topic has had dozens of comments noting that their vibed codebase is bursting at the seams with unaudited unsafe blocks, lightly reviewed by people who seem to not only seem to not understand Rust, but who seem incensed at the idea of needing to understand any programming language in the first place.
They did cite Rust's safety as a motivating factor for the port. That doesn't imply trying to achieve that simultaneously with the language change — which is good, because that would be insane. (Or, if you prefer, even more insane.)
You cannot faithfully port a codebase to a new language while also radically re-architecting it. You have to choose.
They want the safety benefits of Rust going forward; i.e., after it's finished, when they then write new code in Rust.
Yes, tools like Miri, which this very post is about.
Thus far most of the buzz and marketing has been entirely negative from people who are against AI.
* Make a huge deal out of it how “Claude Code enabled Bun team to rewrite 1+ mil of Zig lines to Rust” and write a blogpost, VCs are salivating
* Basic checks fail
* Let Mythos rip the codebase to shreds, spend God knows how much more
* Write a separate blogpost
* Charlatans and smooth brains clap and defend against “delusional anti-AI mob”
* VCs orgasm even harder
Clap, clap, clap. That’s how you make money, folks.
It’s just a standard Pavlovian response of a bootlicker, it can also be triggered if you mention “tax the rich” and “regulate AI hyperscalers”.
Then I realized that the github ui was auto-collapsing a dozen messages in a row that were all completely devoid of any informational value and certainly sourced from forums and community discord channels.
This places everyone in a no-win situation. Someone who has identified critical issues that they believe the majority of a relevant community would be concerned about has good reason to signal-boost as much as they can.
It's a substantial request about very recent changes, and tone-policing it doesn't make it less true. The problem is that the additional attention literally kills the discussion. This also provides cover for people who may be making more emotive or ai-psychosis influenced decisions on the maintainer side.
Projects with a siege mentality which block and ignore criticism tend to go off the rails very quickly. On the other hand, maintainer burnout is inevitable for projects which can't shield maintainers from the anxieties and pathologies of people who seem to think that if they complain about AI enough, everyone else will stop trying to use and improve it it.
Isn't the whole point of AI companies using Rust that it's explicit, safe, and AIs are fairly good at writing it?
Related: If AI writes your code, why use Python? (which notes why Rust has taken off for LLMs) https://news.ycombinator.com/item?id=48100433
If you find a bug, just go straight to blog posts and CVEs to denounce this idiocy. It ranks higher on Google.
The "rewrite it in rust" commit is +1M lines of code. Humans haven't looked at that in depth. In about a week, they saw the tests passed and pushed it to main. Now people have started to look through it and are pointing out glaring issues. And the solution is just going to be "feed it to another AI and ask it to fix it".
The entire codebase is slop now. Nobody knows what it does. It manages to pass some tests, but its largely a black box just on the basis of humans haven't read it yet. The code isn't guaranteed to be anything close to 1:1 with the old codebase. Its probably vaguely shaped like the old codebase, but new bugs could be there, old bugs could be there, nobody knows anything yet.
Its going to be interesting to see how recoverable this is. They are almost certainly going to just hand every file to an AI, say "look for soundness issues and fix them" and then what? If AI is making huge, sweeping changes to the code so frequently that humans can't keep up, is that really maintainable? The only solution appears to be "even more AI" while anybody that looks closely gets scared away by the too-large-to-comprehend-and-entirely-slop codebase.
This kind of thing has been happening with many smaller projects already, but now its a larger project and happening in a much more public way, with the intent to replace human-written, mostly-understood code with slop. I suspect the same thing, with the same problems, is happening inside all the largest companies, just not quite as obviously.
That's the idea, to transform businesses to be wholly dependent on "AI" service to develop software. What better way than to re/write entire codebases until no human being understands it.
The Zig project know this, and its so-called "anti-AI" policy is actually pro-community and cultivating human understanding. It's not about the tool or technology, per se, it's about people, knowledge, and sustainability.
In contrast, the Bun project is demonstrating how they doesn't care about any of that, YOLO-ing its way to losing the trust of its users, contributors, and maintainers. Oh well, AI will maintain the project now, since no one else can.
I am not against AI code, it can be perfectly fine.
The principle issue in my mind is the rate of change.
Once you rewrite a code base like this (in a week no less) the only way to work on it in the future is using AI tools because no single person has any knowledge about any specific piece of code base any more.
AI generated code that is run through a classic PR process would potentially be fine, but then you sorta lose the entire point of using AI.
There’s no way they had time to review the code. This just seems so wildly irresponsible for such an important and high profile project.
But I think their true strategy is to have AI produce "fixes" like these which will end up infecting the entire codebase: https://github.com/oven-sh/bun/pull/30728
I'd be concerned that by jumping onboard with this sort of development process I'd lose touch with how to engineer software in a detail-oriented or remotely rigorous way.
It also makes me question what sort of value the entire Bun project ever had if a drop-in replacement can just be thrown in here like it's nothing. Why do we need all these JS runtimes again?
The AI bubble is so large that we've also forgotten how useless and dumb a lot of software engineering labor was even before LLMs came along. We were already in a bubble.
All that is to say, I think it's useful to reframe some conversations about AI as, "if AI can accomplish this task, was it ever actually valuable?" I think for some specific things, the answer will be yes, but the tech industry has been huffing its own farts for so long I really don't think anyone has sight anymore of what's economically valuable in a ground truth sense. Much like LLMs themselves, this confusion pollutes the entire well of discourse about their economic utility.
"Zig, let me Ai you"
"no"
*Ai's Zig fork, suffers from memory bugs*
"Well I'm moving!"
*Ai's code into Rust, suffers from memory bugs*
I think they shat over the community who trusted them by trying to advertise their owner company
The code they are complaining about is not safe code, it is unsafe code that exposes a supposedly but not actually safe interface. They demonstrate this by using the interface to get undefined behavior.
You can see this rather directly by how miri points to the exact line of unsafe code that results in undefined behavior (which isn't something miri can always do, but it can in this instance).
What matters more is if it does what you want it to do, and is well maintained.
1 week turnaround I guess is what they meant.
Will definitely use that going forward
Didn't find anything on my existing vibecoded rust projects but can't hurt
- Its a throw thing at the wall and see what sticks situation
- LLMs will improve*
- Using LLMs in an agentic way will improve (git worktrees, sliced PRs, spec driven steps)
So what happened here is a mess, but you gotta break a few eggs to make a souffle.
It's a learning step and I am glad it happened, there will be so many things to debrief from this.
I don't use Bun or Rust but fair play to them having a punt.
<Shameless plug> I have been working with Claude code to spec out and bring back to life a Spring Boot starter library for Apache Solr search
https://github.com/tomaytotomato/spring-data-solr-lazarus
There were a few points I had to steer it but the result has been a good implementation.
What would have been significantly better is just rewriting Claude in a language that's actually well suited to what it's doing in the first place (which could well be Rust, Codex is written in it as prior art). It's funny how the vibe coding promoters are keen on things like this, rewriting other codebases as fast as possible with little quality checking, but they are still defensive of their own code.
My grandpa told my dad never to show a client a work in progress - You told them when you'd get the work done, and they can see the finished result when it's ready.
It's just a story so don't wrap yourself around the axle with counter-examples. I think it's fair to say that an open-source project going through a language translation is going to have transitional periods as they shake things out, and criticizing every snapshot as some proof that they're incompetent is useless.
I guess they can just hook up the agent to Miri checks and let it grind away, and see what happens.
Strong deja-vu about that time Cursor tried to slop together a browser and tried to bury dissent when people pointed out how hilariously terrible the whole thing was.
Jarred is an exceptional 1% engineer, and its likely he can succeed at this port, to the detriment of naysayers who don't believe there's any chance it's possible.
Step 2: Purchase an entire company for a product that, if you squint, might help paper over the entirely predictable problems that arise from using the wrong tools to implement the wrong architecture, because surely the solution isn’t reevaluating your original engineering choices.
Step 3: Perform a buggy, vibe-code rewrite of the tool you just bought. A tool you only need because — for whatever internal political reasons — sunk cost means you can only keep digging.
Step 4: ???
The goal of a library is to provide the encapsulation such that the unsafety doesn't spread.
If undefined behavior occurs, the fault lies with whoever wrote `unsafe { ... }` in the body of a function. If I write "unsafe" in order to call an unsafe library function, and I don't meet the library function's pre-requisites, then it's my fault. If the library internally writes "unsafe" in order while providing a safe wrapper, and I never actually wrote `unsafe { ... }`. If neither I nor the library wrote `unsafe { ... }`, then it is the fault of the compiler.
Using "in safe Rust" means that `unsafe` doesn't occur either in the user code nor in the library. In this context, since we've heard how many uses of `unsafe { ... }` exist in the Bun rewrite, I'd read "in safe Rust" to mean "without calling any functions marked as unsafe".
In this context "UB" means something different than how you're using it. The UB being mentioned here is the "nasal demons" form, i.e., programs which contain undefined behavior have no defined meaning according to the language semantics.
What you're talking about is probably better described in this context as "unspecified behavior", which is behavior that the language standard does not mandate but does not render programs meaningless. For example, IIRC in C++ the order in which g(), h(), and i() are evaluated in f(g(), h(), and i()) is unspecified - an implementation can pick any order, and the order doesn't have to be consistent, but no matter the order the program is valid (approximately speaking).
Unsafe Rust allows you to tell the compiler “hold my beer”. It’s a concession to the reality that the normal restrictions of Rust disallow some semantically valid programs that you might otherwise want to write. The safeguards work great in most cases, but in some they’re overly restrictive.
In practice, the overwhelming majority of code is able to be written in safe Rust and the compiler can have your back. The majority of the rest is for performance reasons, interacting with external functions like C libraries over FFI, or expressing semantics that safe Rust struggles with (e.g., circular references).
And it's not like Bun when written in Zig has been a beacon of stability either. It has been segfaults all over the place.
I don't see what the big deal is here.
architector4@AGOGUS:/tmp$ git clone --depth=1 'https://github.com/oven-sh/bun' Cloning into 'bun'... … architector4@AGOGUS:/tmp$ cd bun/ architector4@AGOGUS:/tmp/bun$ find -type f -name '*.rs' -exec grep unsafe {} \; | grep -v '//' | wc -l 13255
....Thirteen thousand two hundred and fifty five lines without comments with the word "unsafe" in them in Rust code files across this rewrite.
This is so gross.
I'm a founder of an early-stage startup. I built a precision-editing tool system (called HIC Mouse). It provides coordinate-based addressing, staged batching with atomic rollback, embedded agent guidance, and more. It works well, it's available on VS Code Marketplace, and I've worked for a year and am still grinding every day, working so hard, just to get people to think about trying it, and to get attention paid to it. I did rigorous, careful benchmark research to make sure I wasn't just fooling myself. I incorporated, built a sales pipeline, changed my life by taking a chance and launching a business, and I pound the pavement and toil in obscurity every day and night, trying so hard to get interest in my product. I check every diff painstakingly before committing. I may make tools for AI agents but I am unbelievably careful about reviewing and thoroughly testing their code, and usually rather ruthlessly editing quite a bit further beyond any initial version drafted, long before deciding it is good enough to ship. I take enormous pains to get things right and worry constantly about whether I'm doing enough to make HIC Mouse secure and performant for my users. All I want is to make my users happier and to give them a genuine way to get "surgical, precise edits" that "don't touch the other lines", like we all ask of our AI agents over and over all day if we're using AI.
Or maybe not. Here we have Bun. Who cares about 90K GitHub Stars and massive community engagement -- just go crap all over them, all at once, with this AI tripe that you obviously neither tested in any meaningful manner, nor documented, nor read, I am assuming, before merging the whole bloated mess to production. What a disgraceful way to treat your users! I would be so grateful if I had a tiny fraction of the interest in my project that the Bun team has. I could never imagine shipping this garbage in a million years.
I'm sorry to vent but this just isn't defensible. It's the very worst of AI. I'm not going to wish ill on Bun, but it just makes me sad that I spend so much effort, work so hard to do things right, and painstakingly review everything because it's not just me any more and I do have folks who depend on my code being reliable and secure. And meanwhile, Bun just gives a huge middle finger to 90k+ starred supporters not to mention the millions of users who didn't click on the star but rely on the library, by acting this disrespectfully and disgracefully towards their own users. How they didn't take one look at this and promptly revert and apologize is simply beyond me. Again, sorry to vent, but this made me irrationally mad.
They got bought out. By the tech equivalent of private equity. Every community in the USA & in most of the world is aware what happens when the friendly neighborhood business you've supported & relied on sells.
This is an old & systemic capitalistic phenomenon more than it is anything specific to AI. Hopefully someday we can figure out a real solution.
In fact using the word "rewrite" itself is pretty inaccurate.
As has been mentioned the goal was a port so they "could" eventually rewrite most of it to be idiomatic rust. The main benefit of this now is the compiler and being able to use these tools to fix issues that were already being hidden when it was in zig.
If you go into this codebase expecting to see idiomatic rust and get angry when it's not there, you are going in with the entirely incorrect attitude.
It's understandable how people see it as AI slop or whatever given the division among developers at the moment. But please see it for what it is instead of just jumping to conclusions.
They may have said that, but quite clearly the value they actually get out of it is getting the headline "AI reimplements complex, broadly used software in 2 weeks, but makes it way better because it's rust now" in front of a million people's eyes, only 1% of whom will ever find out it was mostly fluff
This is entirely disingenuous. Jarred has already made it clear what value they get out of moving off of Zig. Yes they used AI heavily to attempt this goal but I don't see what the big issue is. They haven't even released it yet and Anthropic themselves have said 0 about this.
The "headlines" thus far are really just people completely uninvolved with Bun and with all to gain by perpetrating "AI BAD".
My honest take: the big issue isn't "what if it goes wrong" its the fear that a migration of this size works out of the box and being done almost entirely by AI.
I wonder what are the real legitimate use-cases for "unsafe" in the first place, it is there for a reason?
In my application I'm able to guarantee that there is no modification to the backing file by making them read-only and ensuring nobody messes with them, but that guarantee exists outside of rust. So -- unsafe with a big SAFETY comment explaining the requirements if you use it.
Much rust code will never use unsafe. Systems code is likely to use a bit but also to know what it's doing.
Things like this port of bun are unusual and presumably transitory on the way to an implementation with minimal use of unsafe.
