3 ms·

How many memory safety bugs have you encountered? How many many of these were ownership problems that could only be solved with a strict borrow checker and cou

by twp 4y ago

How many memory safety bugs have you encountered? How many many of these were ownership problems that could only be solved with a strict borrow checker and could not be solved with a garbage collector?

Cyph0n 4y ago
Think of it this way: every time the borrow checker throws a fit, it very likely saved you from a memory safety bug. Now, whether or not you would have made the same mistake in C or C++ is a different issue. GC is unacceptable for some applications. Generally speaking, shifting the memory safety checks to compile time results in better runtime performance. Is the added complexity worth the performance gain? That’s for you to decide.
- zozbot234 4y ago
  > 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.
  - steveklabnik 4y ago
    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.
    - zozbot234 4y ago
      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.
      - steveklabnik 4y ago
        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.
  - Cyph0n 4y ago
    Yep, you have a good point. My wording was indeed a bit strong. Thanks for providing the additional context.
  - enedil 4y ago
    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.
adgjlsfhk1 4y ago
Garbage collectors are an alternate solution to memory safety, but projects written in C++ aren't using a language with a garbage collector.
NoGravitas 4y ago
Programmers would literally rather learn a new language with alien syntax and unfamiliar idioms than ~~go to therapy~~ use a garbage collector.
elihu 4y ago
Most applications should probably just be written in a garbage collected language, but Rust and C and C++ are mainly there to support use cases where running a garbage collector isn't appropriate. (I.e. you're trying to get your code to run as fast as possible, and don't mind doing some extra work.) Maybe there's a reasonable case that Rust has developed to the point where an experienced Rust user is just as productive as an experienced Java or C# user even when it comes to tasks that aren't performance critical. For my part I think I'd rather use Haskell than Rust for tasks where GC overhead isn't a deal-breaker.

by twp 4y ago

Cyph0n 4y ago

Think of it this way: every time the borrow checker throws a fit, it very likely saved you from a memory safety bug. Now, whether or not you would have made the same mistake in C or C++ is a different issue. GC is unacceptable for some applications. Generally speaking, shifting the memory safety checks to compile time results in better runtime performance. Is the added complexity worth the performance gain? That’s for you to decide.

zozbot234 4y ago
> 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.
- steveklabnik 4y ago
  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.
  - zozbot234 4y ago
    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.
    - steveklabnik 4y ago
      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.
- Cyph0n 4y ago
  Yep, you have a good point. My wording was indeed a bit strong. Thanks for providing the additional context.
- enedil 4y ago
  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.

adgjlsfhk1 4y ago

Garbage collectors are an alternate solution to memory safety, but projects written in C++ aren't using a language with a garbage collector.

NoGravitas 4y ago

Programmers would literally rather learn a new language with alien syntax and unfamiliar idioms than ~~go to therapy~~ use a garbage collector.

elihu 4y ago

Most applications should probably just be written in a garbage collected language, but Rust and C and C++ are mainly there to support use cases where running a garbage collector isn't appropriate. (I.e. you're trying to get your code to run as fast as possible, and don't mind doing some extra work.) Maybe there's a reasonable case that Rust has developed to the point where an experienced Rust user is just as productive as an experienced Java or C# user even when it comes to tasks that aren't performance critical. For my part I think I'd rather use Haskell than Rust for tasks where GC overhead isn't a deal-breaker.