There's a book that changed a lot of the way I think about attention and media [0]. The book isn't very good, but it flags something relevant here. There is a huge asymmetry between the reach of a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks), and the relatively small reach of a correction (often just a footnote on an old article, here a GH issue).
This asymmetry is well understood by marketing and PR professionals, and actively exploited.
> a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks)
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.
No, and there's been a lot of confusion about that on this website.
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.
Yeah, exactly. The typical approach is to do a mechanical translation such as with rust2c, that is full of unsafe, and then gradually refactor safety in.
A bug-for-bug port to Rust is the first step to fixing that. Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code. The difference is now it's known where effort can be dedicated in order to one day have a memory-safe release of Bun. People have absolutely lost their mind over this and completely forgotten the benefits Rust gives you. I feel like I've gone back 10 years reading threads about the Rust port of Bun these are the exact same arguments we see from people advocating continued use of C++.
Hmmm, given the general mood in this case, I feel like there's a lot of people keen to find any criticism of the code they can and amplify it as possible. Most of it strikes me as relatively shallow at the moment, though (that is, apart from the fact that merging such a large LLM assisted port is certainly a, uh _bold_ move (to put it lightly), there's not much that people are pointing out about the actual result that feels like it's worse than any other port in progress, but there is definitely a lot of hay being made about any issue that is found).
Not just marketing and PR, the mainstream media knows that pushing out BS and then retracting it later can have lasting effects because people will remember the original article / headline, and never see the correction.
only the mainstream media knows about this? Quite odd to qualify media this way here, when most of all media uses this mechanism. We also forgot politicians who are experts in this field.
What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it? You could do a one-to-one mapping of language constructs, hardcoding patterns in your codebase, and as one friend put it "Tbh they could've just hooked up zig translate-c to c2rust". They would get deterministic translation, would probably have not been a heavy investment to build, and the output would have the same assurances as the input.
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?
> "Tbh they could've just hooked up zig translate-c to c2rust".
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.
“Tbh they could've just hooked up zig translate-c to c2rust”
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.
I was a little shocked that they could get it fully working in a week to be honest. My side project is a very similar ambition (https://tsz.dev) but I am in no way claiming success. i keep adding more and more tests to ensure things works. Even after all of TypeScript's own tests pass I am finding bugs which I was totally expecting.
The bar for matching tsc's behavior is really _really_ high. see:
This doesn't seem surprising, given the straight translation that they prompted.
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.
It's not surprising that a mostly straightforward translation to (partly unsafe) Rust exhibits UB.
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.
I suspect they're probably buying HN accounts to actively shill it, too. I've seen a lot of what seems to be inorganic defense of this, including one post from an account that hasn't posted in over a year. It beggars belief that the first thing to compel someone to post in a year would be to defend a buggy, completely unreviewed mess of a 1m LoC port being forced onto an open source project for Anthropic's advertising campaign.
I dunno, I am commenting on it mainly because I find the intensity of the anger and accusations of bad faith to be pretty out of proportion with what's actually happening, and I kind of value pushing back on such things to try to moderate the tone of the discussion (not as a devil's advocate thing per se, but more I am more likely to comment if I feel like the average vibe is unreasonable).
If you can increase your reach, why not do it? Also, HN has better reputation among tech circles than Reddit and is less niche than other resources. Modern marketing hits everything.
I think HN has an outsized influence in the industry, for its size. There are a lot of big tech employees and startup founders reading it. Account purchasing absolutely happens, I've discovered and gotten banned at least a dozen years-old accounts that were blatantly sold and puppeteered by bots in the past. The comments aren't obviously bot-written this time around, so I can't conclusively prove it happened in this case, but it is a thing that happens in general and something to be aware of. There's also vote selling to promote things onto the front page. Given how cheap shilling on HN is, and the fact that many will perceive it to be organic while always viewing straightforwards ads skeptically, I wouldn't be surprised if the cost:effectiveness ratio probably beats any other form of advertising.
Not a single person on the Bun team nor Anthropic has yet done anything egregious to market this as anything but a swap to a more memory-safe language with better compiler guarantees.
Thus far most of the buzz and marketing has been entirely negative from people who are against AI.
My take is that most of the buzz is also tied to recent negative opinions of Anthropic themselves due to some of their recent decisions.
That kind of error was expected. I don't see it as an issue against the rewrite. They kept the stable versions on Zig in case ppl needs stability. Eventually, the errors will get fixed.
That kind of error was entirely avoidable. There are well-known tools in the Rust ecosystem that detect this kind of error and while the tools do not detect all instances of UB caused by mistakes in unsafe blocks, it's still considered good practice to run them.
Indeed. My point is that just using the standard tools in the Rust ecosystem - like miri - would have trivially uncovered this error before it made it to the mainline.
I think the only way to interpret a one million line LLM-generated diff with no proper reviews as an employee of Anthropic is that my company no longer has an interest in understanding, or even looking at, its own code.
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.
Sure. I'm completely unaffiliated and think Zig's AI stance is ridiculous & politically-motivated and a port is absolutely justified if they will not budge. Apparently I am deeply in the minority.
The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.
Bun's fork of Zig was just an unsound hack that at best would have produced a strictly inferior speedup compared to our current work with incremental compilation, which is already plenty usable:
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.
Man that issue got way too many comments from non-contributors. I agree that this shouldn't have been merged in in it's current state, but that doesn't mean posting about it on GitHub is a worthwhile way to fix the problem.
Maybe they want a quick switchover and the UB is replicating existing problems so it is net neutral for the codebase (but positive future coz developers can do future work on rust without synchronizing two codebase? ).
exactly. If they wanted to iterate on their port they would add lifetime annotations here, which are the tool Rust be uses to ensure safety. They're just kicking the unsafety block down the road. This accomplishes nothing and is not how you get Rust to deliver its safety promise.
It is really sad and unfortunate that coding has started falling under the omnicause. Low-denominator discourse is invading every space I find interesting and it is difficult to avoid.
"unsafe" is a promise to the compiler that you're going to ensure invariants that the compiler can't check. Rust only promises to eliminate UB if the invariants are held. You can still get UB by violating that promise, as this bug demonstrates.
> I thought the unsafety couldn't "spread" like that in Rust.
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".
I can't tell if you're trolling but `unsafe { crash() }` is safe from the compiler's perspective. Otherwise you wouldn't be able to achieve anything in 'safe' rust, even print to stdout.
That is not Rusts guarantee. The guarantee is that safe rust cannot in itself introduce UB - UB can only ever be introduced in unsafe blocks, but it can then materialize in safe code.
it's more straightforward to write safe rust when rust owns everything, In real world you often are interfacing with underlying libs or systems etc, which you need to treat as invariants but also handle yousrelf manually to make guarantees to compiler. unsafe exists in tons of codebases it's just you have to make sure you encapsulate it properly, which is what this bug is.
Unsafe code can break certain invariants of Rust, as `unsafe` is just a compiler "hold my beer" flag, which is why you're meant to do safety checks in your safe interface around unsafe code. If the unsafe code is wrapped in a way that does no guarding (or does something stupid in general), it is technically marked safe (because you said "rustc, hold my beer" as `unsafe` is also a contract) despite actually being unsafe
I'm sure there have been attempts at defining a language that has no UB, but afaik all meaningful languages have UB in some dark corner or enumerated explicitly. For example, Java thread execution order is UB.
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).
It is only allowed in unsafe blocks. As long as the unsafe blocks are few and well understood then Rust programmers can contain this to a small well defined portion of a program.
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).
OK but the title says "in safe Rust". Am I misunderstanding something? All the replies here are saying how it's allowed in unsafe Rust, which is not what the title says.
Unsafe blocks are you saying to the compiler 'trust me bro, I know this is safe'. But often that relies on some property of the code being true in order for it to actually be safe. Generally speaking, the expectation in rust is that you either encapsulate the code that enforces whatever property you are relying on behind a safe interface, so that it's not possible for other code to use it unsafely, or that you mark the interface itself unsafe so that it's obvious that the code using that interface needs to maintain that property itself. Rust code that doesn't do this will generally be considered buggy by most rust programmers (e.g. if you find a use of safe interfaces in the stdlib that causes a memory safety violation, then you should file a ticket with the rust team), but this is essentially only a social convention of where the blame lies for a bug, not something that compiler itself can enforce (and, for example, you can violate memory safety in rust with only safe std interface by abusing OS interfaces like /proc/self/mem but this is something that most people don't think can be reasonably fixed). The main reason that rust as a language is better in this regard is that it gives much better tools for being able to express that safe interface without giving up performance and that it has the means to mark and encapsulate this safe/unsafe distinction.
Here's some links on this topic which have some examples:
If code in an unsafe block triggers undefined behavior, then the assumptions the compiler makes regarding safety will no longer be true, and purely safe code (code with no unsafe blocks) is no longer guaranteed to be safe. This is what's happening in the example the person on Github wrote in the issue.
So many people are fundamentally misunderstanding everything about this rewrite.
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.
> As has been mentioned the goal was a port so they "could" eventually rewrite most of it to be idiomatic rust.
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
> quite clearly the value they actually get out of it is getting the headline
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.
Dumbest point ever.
There is no value for this issue.
I don't agree with the way they did the rewrite, but they did the rewrite, and this post contributes nothing, beside making the author seem childish.
If it had any real contribution I would have waved it off, but it really doesn't.
This tribalism and "I'm better than you"-ism and the same reason everybody hated the stack overflow community, and the rust community as well.
There's a book that changed a lot of the way I think about attention and media [0]. The book isn't very good, but it flags something relevant here. There is a huge asymmetry between the reach of a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks), and the relatively small reach of a correction (often just a footnote on an old article, here a GH issue).
This asymmetry is well understood by marketing and PR professionals, and actively exploited.
[0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying
> a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks)
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.
No, and there's been a lot of confusion about that on this website.
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.
Yeah, exactly. The typical approach is to do a mechanical translation such as with rust2c, that is full of unsafe, and then gradually refactor safety in.
But nobody makes announcements and blog posts about running that.
The author kept bragging about classes of bugs that would not happen with Rust.
A bug-for-bug port to Rust is the first step to fixing that. Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code. The difference is now it's known where effort can be dedicated in order to one day have a memory-safe release of Bun. People have absolutely lost their mind over this and completely forgotten the benefits Rust gives you. I feel like I've gone back 10 years reading threads about the Rust port of Bun these are the exact same arguments we see from people advocating continued use of C++.
Hmmm, given the general mood in this case, I feel like there's a lot of people keen to find any criticism of the code they can and amplify it as possible. Most of it strikes me as relatively shallow at the moment, though (that is, apart from the fact that merging such a large LLM assisted port is certainly a, uh _bold_ move (to put it lightly), there's not much that people are pointing out about the actual result that feels like it's worse than any other port in progress, but there is definitely a lot of hay being made about any issue that is found).
Pretty typical of reddit-resembling sites like HN. People here are very politically, uh, involved.
Is this the concept that's referred to in the quote "a lie can travel halfway around the world before the truth puts on its shoes"?
Not just marketing and PR, the mainstream media knows that pushing out BS and then retracting it later can have lasting effects because people will remember the original article / headline, and never see the correction.
only the mainstream media knows about this? Quite odd to qualify media this way here, when most of all media uses this mechanism. We also forgot politicians who are experts in this field.
What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it? You could do a one-to-one mapping of language constructs, hardcoding patterns in your codebase, and as one friend put it "Tbh they could've just hooked up zig translate-c to c2rust". They would get deterministic translation, would probably have not been a heavy investment to build, and the output would have the same assurances as the input.
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?
> "Tbh they could've just hooked up zig translate-c to c2rust".
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.
What they’ve done here isn’t safe either, and doesn’t have the consistent translation of rust2c.
>What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it?
This would require experience, judgement, and most of all humility.
“Tbh they could've just hooked up zig translate-c to c2rust”
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.
> What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it?
AI disproportionately empowers the stupid and evil
> why not just build a translation tool for it?
They did ;) a highly dynamic one...
Because they aren't trying to raise billions of dollars to build a translation tool.
I was a little shocked that they could get it fully working in a week to be honest. My side project is a very similar ambition (https://tsz.dev) but I am in no way claiming success. i keep adding more and more tests to ensure things works. Even after all of TypeScript's own tests pass I am finding bugs which I was totally expecting.
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.
This doesn't seem surprising, given the straight translation that they prompted.
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.
They'll just need to update the prompt with "make sure there's no UB", and it should be good.
Yes, and seems pretty clear you can now backpressure the rewrite with tools like miri to have Claude Code automatically improve it.
engineers will do anything to avoid actually coding
This is, ironically, a pretty good idea. ...Minus the fact that you're presumably talking about having AI generate it all instead.
It's not surprising that a mostly straightforward translation to (partly unsafe) Rust exhibits UB.
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.
This Bun rewrite feels like a potential Mythos marketing stunt.
I suspect they're probably buying HN accounts to actively shill it, too. I've seen a lot of what seems to be inorganic defense of this, including one post from an account that hasn't posted in over a year. It beggars belief that the first thing to compel someone to post in a year would be to defend a buggy, completely unreviewed mess of a 1m LoC port being forced onto an open source project for Anthropic's advertising campaign.
I dunno, I am commenting on it mainly because I find the intensity of the anger and accusations of bad faith to be pretty out of proportion with what's actually happening, and I kind of value pushing back on such things to try to moderate the tone of the discussion (not as a devil's advocate thing per se, but more I am more likely to comment if I feel like the average vibe is unreasonable).
I'm not sure that HN is that influential that buying up a few accounts would matter. To what end?
If you can increase your reach, why not do it? Also, HN has better reputation among tech circles than Reddit and is less niche than other resources. Modern marketing hits everything.
I think HN has an outsized influence in the industry, for its size. There are a lot of big tech employees and startup founders reading it. Account purchasing absolutely happens, I've discovered and gotten banned at least a dozen years-old accounts that were blatantly sold and puppeteered by bots in the past. The comments aren't obviously bot-written this time around, so I can't conclusively prove it happened in this case, but it is a thing that happens in general and something to be aware of. There's also vote selling to promote things onto the front page. Given how cheap shilling on HN is, and the fact that many will perceive it to be organic while always viewing straightforwards ads skeptically, I wouldn't be surprised if the cost:effectiveness ratio probably beats any other form of advertising.
hn appears in google news now
> I've seen a lot of what seems to be inorganic defense of this, including one post from an account that hasn't posted in over a year.
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”.
Not a single person on the Bun team nor Anthropic has yet done anything egregious to market this as anything but a swap to a more memory-safe language with better compiler guarantees.
Thus far most of the buzz and marketing has been entirely negative from people who are against AI.
My take is that most of the buzz is also tied to recent negative opinions of Anthropic themselves due to some of their recent decisions.
* Spend God knows how many dollars in unlimited tokens to do the rewrite
* 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.
Finally someone gets the point of this.
just as overhyped and disappointing?
That kind of error was expected. I don't see it as an issue against the rewrite. They kept the stable versions on Zig in case ppl needs stability. Eventually, the errors will get fixed.
That kind of error was entirely avoidable. There are well-known tools in the Rust ecosystem that detect this kind of error and while the tools do not detect all instances of UB caused by mistakes in unsafe blocks, it's still considered good practice to run them.
>There are well-known tools in the Rust ecosystem that detect this kind of error
Yes, tools like Miri, which this very post is about.
Indeed. My point is that just using the standard tools in the Rust ecosystem - like miri - would have trivially uncovered this error before it made it to the mainline.
Indeed this was caught by a well-known tool, Miri, that detected this error.
I think the only way to interpret a one million line LLM-generated diff with no proper reviews as an employee of Anthropic is that my company no longer has an interest in understanding, or even looking at, its own code.
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.
So Bun saga has been
"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*
Sure. I'm completely unaffiliated and think Zig's AI stance is ridiculous & politically-motivated and a port is absolutely justified if they will not budge. Apparently I am deeply in the minority.
The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.
Bun's fork of Zig was just an unsound hack that at best would have produced a strictly inferior speedup compared to our current work with incremental compilation, which is already plenty usable:
- June 2025 core team starts using it with the zig compiler itself https://ziglang.org/devlog/2025/#2025-06-14
- April 2026 https://ziglang.org/devlog/2026/#2026-04-08
> Zig's AI stance is ridiculous & politically-motivated
It's literally an issue with our business model to mess with our contributor pipeline, can't get more concrete than this.
https://kristoff.it/blog/contributor-poker-and-ai/
Philosophically motivated, sure. In what way is the Zig foundation's AI stance political?
I think that we only see these bans because AI has become such a massive political issue in the last year.
Define “political” when it comes to Zig and AI.
This issue is misleading.
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.
Man that issue got way too many comments from non-contributors. I agree that this shouldn't have been merged in in it's current state, but that doesn't mean posting about it on GitHub is a worthwhile way to fix the problem.
Maybe they want a quick switchover and the UB is replicating existing problems so it is net neutral for the codebase (but positive future coz developers can do future work on rust without synchronizing two codebase? ).
If that was true, then I would expect followups to reduce UB and unsafe in general, or at least requiring a lifetime for caller-owned memory.
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
exactly. If they wanted to iterate on their port they would add lifetime annotations here, which are the tool Rust be uses to ensure safety. They're just kicking the unsafety block down the road. This accomplishes nothing and is not how you get Rust to deliver its safety promise.
It is really sad and unfortunate that coding has started falling under the omnicause. Low-denominator discourse is invading every space I find interesting and it is difficult to avoid.
I speculate the real goal is to have that fixed over time, and then use it as precious training data for Rust capabilities
UB = undefined behaviour, for anyone else who was puzzled.
I thought Rust treated undefined behaviour as a compiler bug? Does anyone know what's actually happening here?
"unsafe" is a promise to the compiler that you're going to ensure invariants that the compiler can't check. Rust only promises to eliminate UB if the invariants are held. You can still get UB by violating that promise, as this bug demonstrates.
But the title here says "in safe Rust", no? Is the unsafe code causing UB in safe code? I thought the unsafety couldn't "spread" like that in Rust.
> I thought the unsafety couldn't "spread" like that in Rust.
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".
It can spread into safe code when you build an incorrect "safe" abstraction around unsafe code. Which the Bun Rust port apparently has.
I can't tell if you're trolling but `unsafe { crash() }` is safe from the compiler's perspective. Otherwise you wouldn't be able to achieve anything in 'safe' rust, even print to stdout.
That is not Rusts guarantee. The guarantee is that safe rust cannot in itself introduce UB - UB can only ever be introduced in unsafe blocks, but it can then materialize in safe code.
Ah OK, that makes sense, thanks.
it's more straightforward to write safe rust when rust owns everything, In real world you often are interfacing with underlying libs or systems etc, which you need to treat as invariants but also handle yousrelf manually to make guarantees to compiler. unsafe exists in tons of codebases it's just you have to make sure you encapsulate it properly, which is what this bug is.
If you use unsafe improperly, it is possible to encounter UB in "safe" code which relies on the unsafe code being correct.
Unsafe code can break certain invariants of Rust, as `unsafe` is just a compiler "hold my beer" flag, which is why you're meant to do safety checks in your safe interface around unsafe code. If the unsafe code is wrapped in a way that does no guarding (or does something stupid in general), it is technically marked safe (because you said "rustc, hold my beer" as `unsafe` is also a contract) despite actually being unsafe
UB != unsafe
https://doc.rust-lang.org/reference/behavior-considered-unde...
I'm sure there have been attempts at defining a language that has no UB, but afaik all meaningful languages have UB in some dark corner or enumerated explicitly. For example, Java thread execution order is UB.
> For example, Java thread execution order is UB.
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).
It is only allowed in unsafe blocks. As long as the unsafe blocks are few and well understood then Rust programmers can contain this to a small well defined portion of a program.
Safe Rust does.
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).
OK but the title says "in safe Rust". Am I misunderstanding something? All the replies here are saying how it's allowed in unsafe Rust, which is not what the title says.
Unsafe blocks are you saying to the compiler 'trust me bro, I know this is safe'. But often that relies on some property of the code being true in order for it to actually be safe. Generally speaking, the expectation in rust is that you either encapsulate the code that enforces whatever property you are relying on behind a safe interface, so that it's not possible for other code to use it unsafely, or that you mark the interface itself unsafe so that it's obvious that the code using that interface needs to maintain that property itself. Rust code that doesn't do this will generally be considered buggy by most rust programmers (e.g. if you find a use of safe interfaces in the stdlib that causes a memory safety violation, then you should file a ticket with the rust team), but this is essentially only a social convention of where the blame lies for a bug, not something that compiler itself can enforce (and, for example, you can violate memory safety in rust with only safe std interface by abusing OS interfaces like /proc/self/mem but this is something that most people don't think can be reasonably fixed). The main reason that rust as a language is better in this regard is that it gives much better tools for being able to express that safe interface without giving up performance and that it has the means to mark and encapsulate this safe/unsafe distinction.
Here's some links on this topic which have some examples:
https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://www.ralfj.de/blog/2016/01/09/the-scope-of-unsafe.htm...
If code in an unsafe block triggers undefined behavior, then the assumptions the compiler makes regarding safety will no longer be true, and purely safe code (code with no unsafe blocks) is no longer guaranteed to be safe. This is what's happening in the example the person on Github wrote in the issue.
They are using unsafe since large portions of Bun is interfacing with other unsafe codebases. Together with a "1:1" rewrite from Zig to Rust.
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.
So many people are fundamentally misunderstanding everything about this rewrite.
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.
> As has been mentioned the goal was a port so they "could" eventually rewrite most of it to be idiomatic rust.
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
> quite clearly the value they actually get out of it is getting the headline
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.
This had to happen, for many reasons:
- 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.
A souffle has not been made
Indeed, more of a frambled egg. Lets see what happens in two years time.
"Port of large memory unsafe codebase has a memory safety bug, news at 11."
I don't see what the big deal is here.
Dumbest point ever. There is no value for this issue. I don't agree with the way they did the rewrite, but they did the rewrite, and this post contributes nothing, beside making the author seem childish. If it had any real contribution I would have waved it off, but it really doesn't. This tribalism and "I'm better than you"-ism and the same reason everybody hated the stack overflow community, and the rust community as well.
The issue author is most likely quite literally a child.