4 ms·

The difference is every line of C can do something wrong while very few lines of Rust can. It's much easier to scrutinize a small well contained class with tool

• uecker 2y ago
  If you limited wrong to "memory safe" and also ignore that unsafe parts violating invariants can make safe parts of Rust to be wrong.
  • Dylan16807 2y ago
    > If you limited wrong to "memory safe" Yes, because this is a discussion about the value of "unsafe", so we're only talking about the wrongs that are enabled by "unsafe". > and also ignore that unsafe parts violating invariants can make safe parts of Rust to be wrong. If I run a line of code that corrupts memory, and the program crashes 400 lines later, I don't say the spot where it crashes is wrong, I say the memory corrupting line is wrong. So I disagree with you here.
    • uecker 2y ago
      It does not invalidate an argument that you do not want to talk about it. Regarding the second point: yes, you can then blame the "unsafe" part but the issue is that the problem might not be so localized as the notion of "only auditing unsafe blocks is sufficient" implies. You may need to understand the subtle interaction of unsafe blocks with the rest of the program.
      • dwattttt 2y ago
        > the problem might not be so localized as the notion of "only auditing unsafe blocks is sufficient" implies It depends on what you consider "problem" can mean. An unsafe function needs someone to write unsafe in order to call it, and it's on that calling code to make sure the conditions needed to call the unsafe function are met. If that function itself is safe, but still let's you trigger the unsafe function unsafely? That function, which had to write 'unsafe', has a bug: either it's not upholding the preconditions of the unsafe function it's calling, or it _can't_ uphold the preconditions without their own callers also being in on it, in which case they themselves need to be an unsafe function (and consider whether their design is a good one). In this way, you'll always find unsafe 'near' the bug.
        • uecker 2y ago
          In other words, somebody made an error somewhere.
          • dwattttt 2y ago
            You're thinking of C; Rust forced that somebody to write unsafe near it to create the bug.
            • uecker 2y ago
              The bug that can lead to a violation of assumptions required for safety of the unsafe block can be elsewhere. One can hope that it is near the bloc, but there is nothing in Rust enforcing this.
              • Dylan16807 2y ago
                When you write "unsafe", you are promising to the compiler that the unsafe code enforces the assumptions it is making. Unsafe code needs to keep its assumption-laden variables private, and it needs to verify the parameters that safe code sends it. If it doesn't do those things, it's breaking that promise.
      • Filligree 2y ago
        Unsafe blocks have a specific set of requirements they have to abide by. Assuming they successfully do so, it is then guaranteed that no safe code is able to trigger undefined behaviour by calling the unsafe code. Importantly, this can be checked without ever reading any of the safe code.
        • uecker 2y ago
          Let's discuss this example: https://github.com/ejmahler/transpose/blob/e70dd159f1881d86aa50ee01586d04e7a83d8dbe/src/out_of_place.rs https://github.com/ejmahler/transpose/blob/e70dd159f1881d86a... The code is buggy. Where is the bug?
          • lostdog 2y ago
            The most common bug in that type of code is mixing up x and y, or width and height somewhere in your loops, or maybe handling partial blocks. It's not really what Rust aims to protect against, though bounds checking is intended to be helpful here. I don't get the argumentshere. In practice, Rust lowers the risk of most of your codebase. Yeah, it doesn't handle every logic bug, but mostly you can code with confidence, and only pay extra attention when you're coding something intricate. A language which catches even these bugs would be incredible, and I would definitely try it out. Rust ain't that language, but it still does give you more robust programs.
            • uecker 2y ago
              The issue is a memory safety issue, which Rust aims to protect against. But I am not saying Rust is bad. My issue is the complete unreasonable exaggeration in propaganda from "C is completely dangerous and Rust is perfectly safe". And then you discuss and end up with "Rust does not protect against everything, but it still better", which could be the start of a reasonable discussion of how much better it actually is.
              • biorach 2y ago
                > C is completely dangerous and Rust is perfectly safe" Nobody in this conversation said that. If you're actually continuing an argument from somewhere else you should save everyone a lot of time and say so up front, not 10 comments in.
      • Dylan16807 2y ago
        Unsafe blocks have to uphold their invariants while accepting any possible input that safe code can give them. Any subtle interactions enabled by "unsafe" need to be part of the invariants. If they don't do that, it's a bug in the unsafe code, not the safe code using it. If done properly, you can and should write out all the invariants, and a third party could create a proof that your code upholds them and they prevent memory errors. That involves checking interactions between connected unsafe blocks as a combined proof, but it won't extend to "the rest of the program" outside unsafe blocks.
• deleted 2y ago
  [deleted]