6 ms·

So the borrow checker is not necessary in Rust?

trklausss 3y ago
Not at all, you can encase everything on an “unsafe” block and live happy. However you won’t have Rust’s guarantees of fearless concurrency and you expose yourself to other defects related to memory (free after use etc.) If you understand the language, you even program much of the std libraries with unsafe code in them. For more info you can consult the Rustonomicon.
pests 3y ago
Technically the borrow checker only limits the set of valid programs and is not involved with compilation. So if you can write perfectly correct code then you never have to deal with it. Just like when you write perfectly correct syntax you never have to work with the syntax checker.
- steveklabnik 3y ago
  To be a bit more precise: the borrow checker does not change the code generation part of the compiler. If you modified rustc to skip borrow checking, and you passed it a valid Rust program, you would get identical output. However, that doesn't mean that you can disregard the semantic rules that it enforces. It is "involved in compilation" in that sense. Even when writing unsafe code, you are expected to keep up the invariants that the language requires, and the rules of the borrow checker are one part of those invariants.
  - pests 3y ago
    Yes thank you. That was my underlying point without explicitly saying it. That the borrow checker does not influence compilation and just determines if a program is valid or not. Just like you can ignore the syntax checker of languages as long as you never give it incorrect syntax. I guess my core concept is that you wouldn't do these things because they provide value. And that removing the rust borrow checker without restricting what programs you write does not make sense just like trying to pass incorrect syntax to a compiler with the syntax checker removed. That to remove the borrow checker would still require you to still follow all the rules of the borrow checker! Now you just don't know if you did it correctly or not.
    - withinboredom 3y ago
      Sometimes, especially when debugging, you don’t care about being “correct,” freeing memory properly, or any other safeties. You just want to narrow down where a bug is in the code so you can start stepping through the right parts and see what is going on.
      - nickm12 3y ago
        You're putting "correctness" in quotes as though it is a matter of being polite to the machine. The Rust compilation process depends on these invariants so that the code actually executes as written (specifically, has no undefined behavior). I'd argue there is never a very good time to expose your program to undefined behavior, but when you're trying to debug an issue is a particularly bad time. Rust as a language aims to move bugs "to the left" through a stricter compiler. The promise is an environment where building things takes longer, but the things you build are more reliable and the net amount of time debugging (and being exposed to production bugs) is lower.
        withinboredom 3y ago
        It is a matter of being polite when it comes to semantics. Weird is English written in obtuse grammar, but it is still legible. Undefined behavior still compiles into _something_, and if it’s after the code I care about observing, it doesn’t matter. The very first C++ templates compilation was observed through undefined behavior and errors. If you don’t have some way to “escape” from proper semantics, just to experiment, then the language is useless unless you know exactly what you are building before you build it. I guess that makes sense, now that I think about it. I see lots of “rewrite in rust!” But not a lot of new (from whole cloth, innovative) projects from rust. Then again, I’m not really in the rust community or do much in rust except a PR every year or so.
        charlotte-fyi 3y ago
        > and if it’s after the code I care about observing, it doesn’t matter That's not how undefined behavior works, though. Undefined behavior doesn't have an "after." By definition it leaves your entire program in an undefined state, which means its behavior cannot be reasoned about temporally or spatially in this way. Sure, in a simple or trivial case you might "get lucky", but merely by introducing undefined behavior you are no longer capable of observing the code you care about correctly.

Not at all, you can encase everything on an “unsafe” block and live happy. However you won’t have Rust’s guarantees of fearless concurrency and you expose yourself to other defects related to memory (free after use etc.) If you understand the language, you even program much of the std libraries with unsafe code in them. For more info you can consult the Rustonomicon.

pests 3y ago

Technically the borrow checker only limits the set of valid programs and is not involved with compilation. So if you can write perfectly correct code then you never have to deal with it. Just like when you write perfectly correct syntax you never have to work with the syntax checker.

steveklabnik 3y ago
To be a bit more precise: the borrow checker does not change the code generation part of the compiler. If you modified rustc to skip borrow checking, and you passed it a valid Rust program, you would get identical output. However, that doesn't mean that you can disregard the semantic rules that it enforces. It is "involved in compilation" in that sense. Even when writing unsafe code, you are expected to keep up the invariants that the language requires, and the rules of the borrow checker are one part of those invariants.
- pests 3y ago
  Yes thank you. That was my underlying point without explicitly saying it. That the borrow checker does not influence compilation and just determines if a program is valid or not. Just like you can ignore the syntax checker of languages as long as you never give it incorrect syntax. I guess my core concept is that you wouldn't do these things because they provide value. And that removing the rust borrow checker without restricting what programs you write does not make sense just like trying to pass incorrect syntax to a compiler with the syntax checker removed. That to remove the borrow checker would still require you to still follow all the rules of the borrow checker! Now you just don't know if you did it correctly or not.
  - withinboredom 3y ago
    Sometimes, especially when debugging, you don’t care about being “correct,” freeing memory properly, or any other safeties. You just want to narrow down where a bug is in the code so you can start stepping through the right parts and see what is going on.
    - nickm12 3y ago
      You're putting "correctness" in quotes as though it is a matter of being polite to the machine. The Rust compilation process depends on these invariants so that the code actually executes as written (specifically, has no undefined behavior). I'd argue there is never a very good time to expose your program to undefined behavior, but when you're trying to debug an issue is a particularly bad time. Rust as a language aims to move bugs "to the left" through a stricter compiler. The promise is an environment where building things takes longer, but the things you build are more reliable and the net amount of time debugging (and being exposed to production bugs) is lower.
      - withinboredom 3y ago
        It is a matter of being polite when it comes to semantics. Weird is English written in obtuse grammar, but it is still legible. Undefined behavior still compiles into _something_, and if it’s after the code I care about observing, it doesn’t matter. The very first C++ templates compilation was observed through undefined behavior and errors. If you don’t have some way to “escape” from proper semantics, just to experiment, then the language is useless unless you know exactly what you are building before you build it. I guess that makes sense, now that I think about it. I see lots of “rewrite in rust!” But not a lot of new (from whole cloth, innovative) projects from rust. Then again, I’m not really in the rust community or do much in rust except a PR every year or so.
        charlotte-fyi 3y ago
        > and if it’s after the code I care about observing, it doesn’t matter That's not how undefined behavior works, though. Undefined behavior doesn't have an "after." By definition it leaves your entire program in an undefined state, which means its behavior cannot be reasoned about temporally or spatially in this way. Sure, in a simple or trivial case you might "get lucky", but merely by introducing undefined behavior you are no longer capable of observing the code you care about correctly.