4 ms·

> The borrow checker is automatic and works across all variables. Not that I'm such a Rust hater, but this is also a simplification of the reality. The term "f

> The borrow checker is automatic and works across all variables. Not that I'm such a Rust hater, but this is also a simplification of the reality. The term "fighting the borrow checker" is these days a pretty normal saying, and it implies that the borrow checker may be automatic, but 90% of its work is telling you: no, try again. That is hardly "without needing to do much extra at all". That's what you're missing.

junon 2y ago
Maybe I'm spoiled because I work with Rust primarily these days but "fighting the borrow checker" isn't really common once you get it.
- vouwfietsman 2y ago
  A lot has been written about this already, but again I think you're simplifying here by saying "once you get it". There's a bunch of options here for what's happening: 1. The borrow checker is indeed a free lunch 2. Your domain lends itself well to Rust, other domains don't 3. Your code is more complicated than it would be in other languages to please the borrow checker, but you are unaware because its just the natural process of writing code in Rust. There's probably more things that could be going on, but I think this is clear. I certainly doubt its #1, given the high volume of very intelligent people that have negative experiences with the borrow checker.
  - steveklabnik 2y ago
    "But after an initial learning hump, I don't fight the borrow checker anymore" is quite common and widely understood. Just like any programming paradigm, it takes time to get used to, and that time varies between people. And just like any programming paradigm, some people end up not liking it. That doesn't mean it's a "free lunch."
    - vouwfietsman 2y ago
      I'm not sure what you mean here, since in different replies to this same thread you've already encountered someone who is, by virtue of Rusts borrow checker design, forced to change his code in a way that is, to that person, net negative. Again this person has no trouble understanding the BC, it has trouble with the outcome of satisfying the BC. Also this person is writing Vulkan code, so intelligence is not a problem. > is quite common and widely understood This is an opinion expressed in a bubble, which does not in any-way disprove that the reverse is also expressed in another bubble.
      - steveklabnik 2y ago
        "common" does not mean "every single person feels that way" in the same sense that one person wanting to change their code in a way they don't like doesn't mean that every single person writing Rust feels the way that they do.
tialaramex 2y ago
What's hilarious about "fighting the borrow checker" is that it's about the lexical lifetime borrow checking, which went away many years ago - fixing that is what "Non-lexical lifetimes" is about, which if you picked up Rust in the last like 4-5 years you won't even know was a thing. In that era you actually did need to "fight" to get obviously correct code to compile because the checking is only looking at the lexical structure. Because this phrase existed, it became the thing people latch onto as a complaint, often even when there is no borrowck problem with what they were writing. Yes of course when you make lifetime mistakes the borrowck means you have to fix them. It's true that in a sense in a GC language you don't have to fix them (although the consequences can be pretty nasty if you don't) because the GC will handle it - and that in a language like Jai you can just endure the weird crashes (but remember this article, the weird crashes aren't "Undefined Behaviour" apparently, even though that's exactly what they are) As a Rust programmer I'm comfortable with the statement that it's "without needing to do much extra at all".
- sensen7 2y ago
  >In that era you actually did need to "fight" to get obviously correct code to compile because the checking is only looking at the lexical structure. NLL's final implementation (Polonius) hasn't landed yet, and many of the original cases that NLL were meant to allow still don't compile. This doesn't come up very often in practice, but it sure sounds like a hole in your argument. What does come up in practice is partial borrowing errors. It's one of the most common complaints among Rust programmers, and it definitely qualifies as having to fight/refactor to get obviously correct code to compile.
  - steveklabnik 2y ago
    > What does come up in practice is partial borrowing errors. For some people. For example, I personally have never had a partial borrowing error. > it definitely qualifies as having to fight/refactor to get obviously correct code to compile. This is not for sure. That is, while it's code that could work, it's not obviously clear that it's correct. Rust cares a lot about the contract of function signatures, and partial borrows violate the signature, that's why they're not allowed. Some people want to relax that restriction. I personally think it's a bad idea.

junon 2y ago

Maybe I'm spoiled because I work with Rust primarily these days but "fighting the borrow checker" isn't really common once you get it.

vouwfietsman 2y ago
A lot has been written about this already, but again I think you're simplifying here by saying "once you get it". There's a bunch of options here for what's happening: 1. The borrow checker is indeed a free lunch 2. Your domain lends itself well to Rust, other domains don't 3. Your code is more complicated than it would be in other languages to please the borrow checker, but you are unaware because its just the natural process of writing code in Rust. There's probably more things that could be going on, but I think this is clear. I certainly doubt its #1, given the high volume of very intelligent people that have negative experiences with the borrow checker.
- steveklabnik 2y ago
  "But after an initial learning hump, I don't fight the borrow checker anymore" is quite common and widely understood. Just like any programming paradigm, it takes time to get used to, and that time varies between people. And just like any programming paradigm, some people end up not liking it. That doesn't mean it's a "free lunch."
  - vouwfietsman 2y ago
    I'm not sure what you mean here, since in different replies to this same thread you've already encountered someone who is, by virtue of Rusts borrow checker design, forced to change his code in a way that is, to that person, net negative. Again this person has no trouble understanding the BC, it has trouble with the outcome of satisfying the BC. Also this person is writing Vulkan code, so intelligence is not a problem. > is quite common and widely understood This is an opinion expressed in a bubble, which does not in any-way disprove that the reverse is also expressed in another bubble.
    - steveklabnik 2y ago
      "common" does not mean "every single person feels that way" in the same sense that one person wanting to change their code in a way they don't like doesn't mean that every single person writing Rust feels the way that they do.

tialaramex 2y ago

What's hilarious about "fighting the borrow checker" is that it's about the lexical lifetime borrow checking, which went away many years ago - fixing that is what "Non-lexical lifetimes" is about, which if you picked up Rust in the last like 4-5 years you won't even know was a thing. In that era you actually did need to "fight" to get obviously correct code to compile because the checking is only looking at the lexical structure. Because this phrase existed, it became the thing people latch onto as a complaint, often even when there is no borrowck problem with what they were writing. Yes of course when you make lifetime mistakes the borrowck means you have to fix them. It's true that in a sense in a GC language you don't have to fix them (although the consequences can be pretty nasty if you don't) because the GC will handle it - and that in a language like Jai you can just endure the weird crashes (but remember this article, the weird crashes aren't "Undefined Behaviour" apparently, even though that's exactly what they are) As a Rust programmer I'm comfortable with the statement that it's "without needing to do much extra at all".

sensen7 2y ago
>In that era you actually did need to "fight" to get obviously correct code to compile because the checking is only looking at the lexical structure. NLL's final implementation (Polonius) hasn't landed yet, and many of the original cases that NLL were meant to allow still don't compile. This doesn't come up very often in practice, but it sure sounds like a hole in your argument. What does come up in practice is partial borrowing errors. It's one of the most common complaints among Rust programmers, and it definitely qualifies as having to fight/refactor to get obviously correct code to compile.
- steveklabnik 2y ago
  > What does come up in practice is partial borrowing errors. For some people. For example, I personally have never had a partial borrowing error. > it definitely qualifies as having to fight/refactor to get obviously correct code to compile. This is not for sure. That is, while it's code that could work, it's not obviously clear that it's correct. Rust cares a lot about the contract of function signatures, and partial borrows violate the signature, that's why they're not allowed. Some people want to relax that restriction. I personally think it's a bad idea.