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

241–250 of 366 posts

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

#241

Post by [deleted] »

mr_00ff00 wrote: post #85
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” 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.

[deleted]

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

#242

Post by minimaxir »

chrisco255 wrote: post #220
minimaxir wrote: post #165

Earlier quoted context omitted.

I suspect "Rust is fast/low memory utilization" is the more common value proposition, with memory safety as the bonus that can push it over other fast languages. 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

Zig is every bit as fast with typically even lower memory footprint as Rust. The main thing Rust promises that Zig cannot already do natively is memory safety. This is not about Python vs Rust. It is one systems language vs another.

This Rust rewrite instance is explicitly about memory safety by admission of the devs; I was just commenting on the trend.

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

#243

Post by parliament32 »

> oven-sh locked as off topic and limited conversation to collaborators

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.

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

#245

Post by Ar-Curunir »

Dylan16807 wrote: post #201
Ar-Curunir wrote: post #117

Earlier quoted context omitted.

And indeed, the bun team has not done that

Did they not make the announcement? And they definitely promised a blog post even if it's not out yet.

Not on their blog, website, or twitter, so no?

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

#246

Post by Decabytes »

When I was in grad school, my mentor once said, that he didn’t actually see programming as anything more than a tool to solve the problems he needed to solve. As someone who was excited about learning to program, I couldn’t understand it. As I’ve gotten older, I’ve come to understand him more. The language a program is written should be far down the list of reasons to use a programming language. Same with who happens to be the BFDL for the language, or what streamer is using it.

What matters more is if it does what you want it to do, and is well maintained.

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

#247

Post by gpm »

teiferer wrote: post #244

Can somebody explain what the issue is? In particular, if Rust is safe, and this is safe code, then how can there possibly be use-after-free? I thought it's the entire point of the "safe code" thing that it's ..safe by construction.

> and this is safe code,

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

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

#248

Post by fc417fc802 »

weinzierl wrote: post #148
ndiddy wrote: post #59

Earlier quoted context omitted.

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.

Exactly and "[...]and purely safe code (code with no unsafe blocks) is no longer guaranteed to be safe" hits the nail on the head. I take issue with the phrasing of OP's title: "allows for UB in safe rust" . AFAIK there are compiler bugs that allow UB in safe Rust, but this is not what is happening here. We have UB in an unsafe block (which is to be expected) which enables an issue outside in safe code. What is your…

Suppose I initialize something in an unsafe block. I promise the compiler that it's properly initialized, but in reality it isn't. Importantly I never make use of the garbage values in the unsafe block so no UB has occurred - yet.

Later, the garage enters otherwise safe machinery and triggers UB. UB has now happened in safe rust as a result of my earlier contractual violation.

You can extend this example to other scenarios where UB in unsafe begets further UB in safe later on.

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

#249

Post by flomo »

AlotOfReading wrote: post #195
flomo wrote: post #119

Earlier quoted context omitted.

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.

Every language has defined behavior. It's what you expect to happen through a program's execution. Sometimes there will be multiple possibilities, but you can still define them regardless. Laying this out explicitly is the purpose of a standard. Undefined behavior is everything else. C and C++ are relatively unique in that their standards explicitly say "combining these constructs in this way is undefined", and we ca…

Yeah, if I understand correctly, the Rust project has no intention to formally 'define' what unsafe actually does, so its very implicit. Could be anything... so it's the Does It Work? standard.

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

#250

Post by bendmorris »

giancarlostoro wrote: post #128
rattray wrote: post #93

Earlier quoted context omitted.

> why not just build a translation tool for it? They did ;) a highly dynamic one...

I mean, LLMs have been really good at translating code for a while now, which is why I'm more surprised that others are surprised this happened. They claim its a marketing trick despite the fact that they have to manage and maintain a fork of Zig if they don't switch languages.

They don't have to do that at all. They could've used mainline Zig, without their vibe coded changes to it.
Post reply on HN