3 ms·

Learning to work with Rust's borrow checker leaves one with the sinking realization that every C program also has a borrow checker: The very fallible programmer

Learning to work with Rust's borrow checker leaves one with the sinking realization that every C program also has a borrow checker: The very fallible programmer.

microtonal 4y ago
Not just C, any language with mutable aliases references/pointers, which is pretty much every modern language. https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing-bugs.html https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-00...
- eru 4y ago
  Well, Haskell has mutable aliases, references and pointers. But you seldom use them.
  - pdimitar 4y ago
    At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. It's the strategy of the C devs whose memory safety bugs and buffer overflow mistakes we still find to this day, in a number of popular and very widely used programs. ...Nah. We shouldn't go back (and I am not saying you claim so, I am kind of just developing the thought here). Let's have memory safety and algebraic data types and maybe pluggable GC runtimes (if lifetime management proves too difficult which it has at times; not every task is perfectly suited for Rust's borrow checker) and async, and any other goodies that help us solve real problems, and let's not dream of a simpler life. That "simpler life" has failed. We should acknowledge that and move on and work with the reality in front of us. Rust's lifetime management and async runtime(s) can be maddeningly difficult but after being on all parts of the spectrum -- from bash scripts and JS Wild West projects to Rust -- I confidently claim that the more strictness the better. ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it.
    - eru 4y ago
      I mostly agree with you. > At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. However in the case of Haskell, manually mucking around with mutable aliases, references and pointers is culturally similar to using unsafe in Rust. By default in Haskell you are using immutable variables. And if you have multiple threads and want to share mutable state, you typically use software transactional memory. > ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it. Well, Golang has quick compile times, partially because it makes the human do half of the compiler's job. OCaml is indeed something that's more worth aspiring, too. As a compromise, I found that `cargo check` is much quicker than a build and does most of what I need when developing: most of the time, I don't actually care about the resulting binary, I just want the compiler to tell me quickly whether I introduced any errors it can detect.
- throwaway894345 4y ago
  While there are other benefits to the borrow checker, the main one is safe memory management and GC languages get you that much while allowing for faster development.
  - pdimitar 4y ago
    Can't disagree with you at all, even though I want to. I love Rust and I hate having to emulate enums in Golang but the speed of development becomes more and more a deal-breaker the more time I spend with Rust. I might just settle at OCaml, if at all possible. Or, since this is the real life and there are no simple final solutions, I'll likely just become a master of all three. But really, as much as I appreciate Rust for being super strict, I also don't think strict lifetime management is as important for many tasks (though it's a life-saver for some).
    - throwaway894345 3y ago
      Yeah, I 100% agree with hating emulating enums in Go (particularly because there is no safe way to emulate exhaustiveness checks). Personally I haven’t found Ocaml to be any more productive (inadequate libraries, poor tooling, constant futzing with multiple std libraries), but maybe I didn’t commit to it for long enough? That said, I’m starting to do a bit more systems development so I’m excited to dabble a bit more in Rust.
  - bsaul 4y ago
    gc is about memory disposal. IMHO the main purpose of the borrow checker is to ensure proper concurrent memory access, while the memory is still in use. Which gc don't help at all..
    - throwaway894345 3y ago
      I don’t think the main purpose is concurrent memory access considering the enormous share of memory managed by the borrow checker which is never accessed in a concurrent context. Whichever purpose is the “main” purpose hardly matters anyway—the fact of the matter is that Rust makes memory management quite burdensome even though it makes it easier to ensure certain correctness properties.

Learning to work with Rust's borrow checker leaves one with the sinking realization that every C program also has a borrow checker: The very fallible programmer.

microtonal 4y ago

Not just C, any language with mutable aliases references/pointers, which is pretty much every modern language. https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing-bugs.html https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-00...

eru 4y ago
Well, Haskell has mutable aliases, references and pointers. But you seldom use them.
- pdimitar 4y ago
  At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. It's the strategy of the C devs whose memory safety bugs and buffer overflow mistakes we still find to this day, in a number of popular and very widely used programs. ...Nah. We shouldn't go back (and I am not saying you claim so, I am kind of just developing the thought here). Let's have memory safety and algebraic data types and maybe pluggable GC runtimes (if lifetime management proves too difficult which it has at times; not every task is perfectly suited for Rust's borrow checker) and async, and any other goodies that help us solve real problems, and let's not dream of a simpler life. That "simpler life" has failed. We should acknowledge that and move on and work with the reality in front of us. Rust's lifetime management and async runtime(s) can be maddeningly difficult but after being on all parts of the spectrum -- from bash scripts and JS Wild West projects to Rust -- I confidently claim that the more strictness the better. ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it.
  - eru 4y ago
    I mostly agree with you. > At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. However in the case of Haskell, manually mucking around with mutable aliases, references and pointers is culturally similar to using unsafe in Rust. By default in Haskell you are using immutable variables. And if you have multiple threads and want to share mutable state, you typically use software transactional memory. > ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it. Well, Golang has quick compile times, partially because it makes the human do half of the compiler's job. OCaml is indeed something that's more worth aspiring, too. As a compromise, I found that `cargo check` is much quicker than a build and does most of what I need when developing: most of the time, I don't actually care about the resulting binary, I just want the compiler to tell me quickly whether I introduced any errors it can detect.
throwaway894345 4y ago
While there are other benefits to the borrow checker, the main one is safe memory management and GC languages get you that much while allowing for faster development.
- pdimitar 4y ago
  Can't disagree with you at all, even though I want to. I love Rust and I hate having to emulate enums in Golang but the speed of development becomes more and more a deal-breaker the more time I spend with Rust. I might just settle at OCaml, if at all possible. Or, since this is the real life and there are no simple final solutions, I'll likely just become a master of all three. But really, as much as I appreciate Rust for being super strict, I also don't think strict lifetime management is as important for many tasks (though it's a life-saver for some).
  - throwaway894345 3y ago
    Yeah, I 100% agree with hating emulating enums in Go (particularly because there is no safe way to emulate exhaustiveness checks). Personally I haven’t found Ocaml to be any more productive (inadequate libraries, poor tooling, constant futzing with multiple std libraries), but maybe I didn’t commit to it for long enough? That said, I’m starting to do a bit more systems development so I’m excited to dabble a bit more in Rust.
- bsaul 4y ago
  gc is about memory disposal. IMHO the main purpose of the borrow checker is to ensure proper concurrent memory access, while the memory is still in use. Which gc don't help at all..
  - throwaway894345 3y ago
    I don’t think the main purpose is concurrent memory access considering the enormous share of memory managed by the borrow checker which is never accessed in a concurrent context. Whichever purpose is the “main” purpose hardly matters anyway—the fact of the matter is that Rust makes memory management quite burdensome even though it makes it easier to ensure certain correctness properties.