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

61–70 of 366 posts

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

#61

Post by whimsicalism »

rcxdude wrote: post #57
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…

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

[flagged]

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

#62

Post by veidr »

kibwen wrote: post #24
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…

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

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.

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

#63

Post by rcxdude »

applfanboysbgon wrote: post #37
iamricks wrote: post #19

This Bun rewrite feels like a potential Mythos marketing stunt.

[flagged]

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

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

#64

Post by [deleted] »

jnwatson wrote: post #21
Xylakant wrote: post #15

Earlier quoted context omitted.

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 this was caught by a well-known tool, Miri, that detected this error.

[deleted]

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

#65

Post by dtj1123 »

whimsicalism wrote: post #58
NooneAtAll3 wrote: post #48

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.

Philosophically motivated, sure. In what way is the Zig foundation's AI stance political?

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

#66

Post by Anon1096 »

parchley wrote: post #33
kibwen wrote: post #24

Earlier quoted context omitted.

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

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

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

#67

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

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

#68

Post by whateveracct »

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…

[flagged]

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

#69

Post by ModernMech »

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…

Because they aren't trying to raise billions of dollars to build a translation tool.

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

#70

Post by Animats »

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

Post reply on HN