Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"

dangerlibrary

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

stellalo

I speculate the real goal is to have that fixed over time, and then use it as precious training data for Rust capabilities

pesnk

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.

stavros

UB = undefined behaviour, for anyone else who was puzzled.

tlarkworthy

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

stavros

I thought Rust treated undefined behaviour as a compiler bug? Does anyone know what's actually happening here?

tomaytotomato

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.

localhoster

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.

iamricks

This Bun rewrite feels like a potential Mythos marketing stunt.

pohl

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.

jnwatson

"Port of large memory unsafe codebase has a memory safety bug, news at 11." I don't see what the big deal is here.

Jcampuzano2

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.

cptroot

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.

whimsicalism

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.

NooneAtAll3

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*

smasher164

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?

mohsen1

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.

gpm

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.

skrrtww

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.

frumplestlatz

Step 1: Vibe-code a buggy, poorly-performing, 500k+ LoC desktop-installed monstrosity in TypeScript to implement a trivial TUI. Proudly note that you’re meeting a 16ms frame budget … for a trivial chat UI. 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: ???