Hacker News Reader

Comment by zozbot234 | Hacker News Reader

> every time the borrow checker throws a fit, it very likely saved you from a memory safety bug.

This is not even close to being true, the borrow checker does not accept all memory safe programs. It tries to do a good job of accepting programs that are both safe and have simple and elegant guarantees of safety across module boundaries (which is good for extensibility and evolvability).

But there are designs that can only be expressed in Rust by using constructs that replace some of these compile-time guarantees with runtime constraints.

View on HN

I can say, that after quite a bit of experience in C++, and I often wrote code that would be rejected by the borrow checker, even if the code would actually be without issues, if the borrow checker would be disabled. Hard to tell exactly, but it seemed that the false positives outnumbered the real issues. Not saying it was a real problem, but certainly hints at what you said.

It’s more complicated than that. First of all, the parent did day “very likely,” and not that it’s always true. So the disagreement is over the degree.

Second, this can be tough because it is hard to self-evaluate. The two languages have different semantics. Some stuff is UB in Rust, but well defined in C and C++, and some things that are UB in C and C++ are well defined in Rust.

What this means is, while you are correct that Rust will reject some memory safe programs, I’ve also seen so many people over the years ask questions like “why does the borrow checker disallow this?!? It’s this easy in C++!” yet they’re running afoul of semantic differences, or they forgot some property (like thread safety) that isn’t enforced by the compiler in those languages, but rustc catches it.

Tl;dr you’re technically right but in the real world it plays out more subtly than I think you’re giving it credit for.

It's true that there are some things that are "well defined in C/C++ but UB in Rust" but it tends to be stuff that the Rust dev community tries to address over time, by providing facilities for doing the C/C++ thing safely given the minimum required guarantees (and no more than what's truly required). Pinned data is perhaps the clearest example here; "out" pointers and in-place construction is AIUI in the works. Failing to address these issues creates safety concerns, as users will resort to calling code that expects Rust semantics and create UB by doing so.

I agree that the Rust community tries to bring safe alternatives to some of these things, but it's not really relevant to my point here.

> Failing to address these issues creates safety concerns, as users will resort to calling code that expects Rust semantics and create UB by doing so.

Absolutely. What I'm saying is that sometimes this is expressed by users as "I can do this" when they actually can't, which makes it hard to talk about how much the borrow checker truly gets in your way. They're just two different languages with two different sets of semantics, you cannot assume that everything that works well in one works well in the other, in both directions.

Yep, you have a good point. My wording was indeed a bit strong. Thanks for providing the additional context.

Reply on news.ycombinator.com