Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 366 posts

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

#111

Post by Animats »

Animats wrote: post #70
smasher164 wrote: post #60

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 outp…

> "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 com…

The module with the code mentioned is at [1]

This is awful. They have some internal string format borrowed from a Zig library where the address of the item is in the low end of a pointer and the length is at the high end. Why are they doing that in 2026? It lets you save a few bytes at best. It doesn't enforce the Rust rule that strings must be strict UTF-8. It's totally alien to the safe way Rust handles strings.

[1] https://github.com/oven-sh/bun/blob/main/src/bun_core/string...

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

#112

Post by K0nserv »

tadfisher wrote: post #18
tlarkworthy wrote: post #6

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

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

It's been like a day since the merge, presumably such followups are coming.

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

#113

Post by CamouflagedKiwi »

This was 100% a predictable outcome after Bun was acquired. Of course they were going to do something like this.

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.

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

#114

Post by [deleted] »

dangerlibrary wrote: post #2

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 un…

[deleted]

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

#115

Post by Aurornis »

dangerlibrary wrote: post #2

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 un…

I thought you were going to call out the problem in the other direction: There has not been a "big, flashy announcement" because the port is a work in progress. It's not done or released. The only big flashy announcements I see are these drive-by dunk attempts on the work in progress code combined with attempts to imply that they said it was done or perfect.

The rewrite was a code translation meant to be a starting point.

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

The Bun team never made a big announcement that the code is now memory safe. They've been clear that this is the starting point.

Anyone expecting it to be perfect immediately and to have solved all of the memory problems in the original Zig code is arguing with an announcement they imagined, not what the Bun team has said.

Did anyone try to map this code back to the original codebase to see if this memory problem exists in the original codebase?

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

#116

Post by cedws »

mohsen1 wrote: post #67

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

I'm stunned that it went from 'this is an experiment' to merging a ~million lines of (likely) unreviewed code in a week. I have nothing against using agents but to rush something like this and leave the community blindsided seems extremely ameteurish. Like something you'd expect a bright eyed graduate engineer to do.

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

#117

Post by Ar-Curunir »

Dylan16807 wrote: post #87
swiftcoder wrote: post #71

Earlier quoted context omitted.

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.

And indeed, the bun team has not done that

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

#118

Post by [deleted] »

Animats wrote: post #111
Animats wrote: post #70

Earlier quoted context omitted.

> "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 com…

The module with the code mentioned is at [1] This is awful. They have some internal string format borrowed from a Zig library where the address of the item is in the low end of a pointer and the length is at the high end. Why are they doing that in 2026? It lets you save a few bytes at best. It doesn't enforce the Rust rule that strings must be strict UTF-8. It's totally alien to the safe way Rust handles strings. [1…

[deleted]

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

#119

Post by flomo »

krona wrote: post #52
stavros wrote: post #29

Earlier quoted context omitted.

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

I think its a good question, just because the whole UB thing is such an ideological shibboleth.

Maybe its better to think about this in the reverse, where C and C++ has 'defined behavior', but unsafe rust intentionally does not, its just whatever the complier and platform lets you get away with. Ultimately its still just a computer which stores values in memory and jumps to subroutines.

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

#120

Post by pgporada »

Dylan16807 wrote: post #87
swiftcoder wrote: post #71

Earlier quoted context omitted.

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.

There's several blog posts here. https://www.memorysafety.org/initiative/av1/
Post reply on HN