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

211–220 of 366 posts

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

#211

Post by stickfigure »

antonvs wrote: post #156
rcxdude wrote: post #57

Earlier quoted context omitted.

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…

> Most of it strikes me as relatively shallow at the moment It is. We’re what, a week into this exercise? Absolutely everyone criticizing it, with no exceptions, is behaving like a micromanaging middle manager who couldn’t even dream of doing the work themselves. I half want to start a list of “people to ignore”, but such people tend to expose themselves in every other comment anyway.

It may just be different expectations about what the `main` branch means. In my organization we don't merge half-finished work into `main`.

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

#212

Post by dang »

whateveracct wrote: post #73
fastball wrote: post #40

Earlier quoted context omitted.

Yes, and seems pretty clear you can now backpressure the rewrite with tools like miri to have Claude Code automatically improve it.

[flagged]

Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

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

#213

Post by nicce »

sigbottle wrote: post #123

Sorry wasn't there a post literally like a week ago about this being a long term experimental branch and how we needed to not kick the hatchling while it's an egg? 1 week turnaround I guess is what they meant.

Probably planned during Anthropic aquization. No way this would happen without their blessings. This is one way to reduce the community noise.

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

#214

Post by achristmascarl »

I wonder if the publicity around this AI-driven rewrite will function as a (unintentional, or perhaps intentional) far-reaching nerd snipe that results in Rust developers flocking to the project to identify and fix issues.

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

#215

Post by chrisco255 »

whimsicalism wrote: post #153
applfanboysbgon wrote: post #101

Earlier quoted context omitted.

Zig rejected Bun's proposed contribution because it was a bad contribution, which they explained at length. Zig should not be made to "budge" on bad contributions. It seems you think Zig is unreasonable for rejecting bad code that happens to also be AI-generated, but believe it's reasonable for a project to be forced to accept bad code because it is AI?

No, I think Zig should reject bad AI contributions and accept good AI contributions. That is not Zig policy, they reject all AI-authored contributions. Not sure why you're inventing a stance for me to be arguing against, when the Zig compiler stance is publicly articulated as exactly what I'm describing.

The problem as they've mentioned is AI contributors don't learn. They cannot have a working relationship with an AI contributor. The context about ongoing efforts, planned design changes to the language, etc is lost every time Claude is run. There is no way to work with that. People will submit infinite PRs while the core devs are flooded and forced to repeat themselves an infinite number of ways to an infinite number of stochastic prompts and responses.

The zig team is not that big. They don't have 200 core contributors to filter through the noise and mine PRs for "gems".

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

#216

Post by aw1621107 »

repelsteeltje wrote: post #104
aw1621107 wrote: post #72

Earlier quoted context omitted.

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

Great example. So this "unspecified behavior" might turn into the more nasal demon type when g(), h() and i() share mutable state and assume some particular sequential order of execution. No?

Not necessarily. Unspecified behavior and undefined behavior are independent concepts; a language can have one but not the other. As a result, you can have languages where incorrect reliance on unspecified behavior can lead to undefined behavior (e.g., C and C++) and languages where incorrect reliance on unspecified behavior can lead to bugs, but not nasal demons (e.g., Java)

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

#217

Post by dgacmu »

gloosx wrote: post #190

Things get pretty hilarious when you super safe language conrains the keyword "unsafe" :D I wonder what are the real legitimate use-cases for "unsafe" in the first place, it is there for a reason?

Many. Let me give you a very boring example: I use mmap in some of my programs, because it's the easiest/best way to solve the problem I was working on. Mmap is unsafe in rust, because if there are modifications to the backing file it can violate some of rust's assumptions about the behavior of memory not changing unless it was changed by the rust code.

In my application I'm able to guarantee that there is no modification to the backing file by making them read-only and ensuring nobody messes with them, but that guarantee exists outside of rust. So -- unsafe with a big SAFETY comment explaining the requirements if you use it.

Much rust code will never use unsafe. Systems code is likely to use a bit but also to know what it's doing.

Things like this port of bun are unusual and presumably transitory on the way to an implementation with minimal use of unsafe.

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

#218

Post by pornel »

CamouflagedKiwi wrote: post #107
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…

They didn't have to. There's a widely held assumption that Rust == safe, or safer than anything else.

What exactly people mean by "safe(r)" makes all the difference.

It's simply not possible to include all the nuance of safety of a language and all software written in it a single word. This leads to all kinds of miscommunication and strawmanning.

Rust's official line is specific memory safety guarantees, with caveats that it must not be broken by unsafe code, the OS, compiler bugs may happen, etc. Rust also has a bunch of best-effort features that steer users towards more robust code, but can't guarantee it.

This gets twisted in both directions:

- people ignore the caveats and limitations, pretending that Rust promised zero bugs ever, and use any bug in any Rust program as a proof by contradiction that Rust's claims are false.

- or focus solely on the caveats, ignoring all the advancements and incremental improvements, and take a "then why even bother?" There are classes of bugs Rust can't stop. Nothing is foolproof for a sufficiently advanced fool, and an infallible programmer could write bug-free code in any language, which creates a false equivalence between languages.

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

#219

Post by shimman »

bdangubic wrote: post #200
nicce wrote: post #198

Earlier quoted context omitted.

The best kind of marketing is when you don’t need to say it aloud by yourself. Yet, this is constantly in HN front page. Maybe engineered or not but marketing regardless.

engineering is worthless unless you can sell it

What a terribly anti-human sentiment to have.

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

#220

Post by chrisco255 »

minimaxir wrote: post #165
jadar wrote: post #140

> Please consider not vibe coding rust as AIs are not good at writing Rust and also hire a real rust dev Isn't the whole point of AI companies using Rust that it's explicit, safe, and AIs are fairly good at writing it?

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.
Post reply on HN