3 ms·

Rust is designed to remove the entire class of memory safety bugs, yet this comment seems to be a collection of hand wavey disregard for the stark differences i

Rust is designed to remove the entire class of memory safety bugs, yet this comment seems to be a collection of hand wavey disregard for the stark differences in language design.

qbasic_forever 4y ago
Those are just one type of bug. There are plenty of other bugs you can create in rust code and reviewers can't just assume because it's written in rust the code needs less scrutiny.
- ben-schaaf 4y ago
  A whole class of bugs doesn't have to be looked for. How does that not mean it requires less scrutiny?
- mlindner 4y ago
  In my experience those one type of bug are also the hardest bugs to find and fix, even when you know it's sometimes happening. The system can get sufficiently complex such that it's near impossible to find the bug unless you get lucky. And often when you find the bug it can result in an apparently architectural contradiction and it becomes very non-obvious how to fix it as there are two architectural decisions that happen to be at odds with each other rather than a simple mistake.
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.
- 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.

Rust is designed to remove the entire class of memory safety bugs, yet this comment seems to be a collection of hand wavey disregard for the stark differences in language design.

qbasic_forever 4y ago

Those are just one type of bug. There are plenty of other bugs you can create in rust code and reviewers can't just assume because it's written in rust the code needs less scrutiny.

ben-schaaf 4y ago
A whole class of bugs doesn't have to be looked for. How does that not mean it requires less scrutiny?
mlindner 4y ago
In my experience those one type of bug are also the hardest bugs to find and fix, even when you know it's sometimes happening. The system can get sufficiently complex such that it's near impossible to find the bug unless you get lucky. And often when you find the bug it can result in an apparently architectural contradiction and it becomes very non-obvious how to fix it as there are two architectural decisions that happen to be at odds with each other rather than a simple mistake.

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