4 ms·

static code analysis tools can also do it. there's no reason why the borrow checker must be in the compiler proper.

alpaca128 1y ago
There's also no reason to have a separate borrow checker if it could just be integrated in the compiler. When a compiler has a borrow checker that means the language was already designed to enable borrow checking in the first place. And if a language can let you do borrow checking why would you use a separate tool?
- josephg 1y ago
  Also it’s a great way to make sure every library in the ecosystem passes the borrow checker.
  - throwawaymaths 1y ago
    why do you expect compile time static analysis to fail at this? unless youre loading a precompiled asset?
    - josephg 1y ago
      I don't. I think compile time static analysis is great. Upthread you said this: > there's no reason why the borrow checker must be in the compiler proper. On a technical front, I completely agree. But there's an ecosystem benefit to having the borrow checker as part of the compiler. If the borrow checker wasn't in the compiler proper, lots of people would "accidentally forget" to run it. As a result, lots of libraries would end up on crates.io which fail the borrow checker's checks. And that would be a knock on disaster for the ecosystem. But yes, there's nothing stopping you writing a rust compiler without a borrow checker. It wouldn't change the resulting binaries at all.
      - throwawaymaths 1y ago
        > lots of people would "accidentally forget" to run it yeah, like how the sel4 guys accidentally forget to run their static analysis all the time. You put a badge on CI. If you "forget to run" the static analysis, then people get on you for not running it. Or people get on you if you don't have the badge. Just like how people get on people for not writing programs in rust.
        josephg 1y ago
        Q: If we can get men on the moon, why is my lawnmower such a piece of junk? A: The engineers who got us in to space didn’t design your lawnmower. The SeL4 team won’t forget to run their static analysis checks. But most people aren’t at their level. Most people just want to get on with it. The borrow checker is a pain in the neck to learn - and if it were optional, you better believe lots of people would avoid it forever. I may well have been in that camp too - I found it really hard to get my head around it! If you want a modern C-like language without rust’s borrow checker, Zig or Odin is probably a better bet. They’re both fine languages. > Just like how people get on people for not writing programs in rust. Who? Where?
        throwawaymaths 1y ago
        your argument doesn't hold water, because you are appealing to the existence of a schroedinger's programmer that simultaneously would use rust but also wouldn't turn on a borrow checker if it existed in another language. My point is the fact that people use Rust means that people do care. And those people will run static analysis checks (as long those static analysis checks aren't the shitty or overly difficult to run), and they will notice that your library isn't checked. Or, better yet, they will integrate it into their project, run the checker on their project, find the problem in the lazy person's dependency and PR a fix or fork it if the maintainer is an asshole. Here's the thing. Rust is currently "the only game in town" for spatiotemporal memory safety and that is sucking the air out of the atmosphere, because no one wants to invest time into trying other ideas. And that's a shame, because everyone makes assumptions that Rust must be the only way to do spatiotemporal safety (cough cough Ada/Spark). And it gives cover for people to claim things that are presumptuous and totally untested like our schroedinger's programmer here. Rust has a lot lot lot of shitty things in it, like RAII, and proc macros, and pushing you into some incredibly complicated (and privileged) templated types that are doing some things under the hood (remember when rust switched from jemalloc to malloc?), and Rust hasn't ever gotten to keyword generics yet. Those of us who don't want that kind of BS in our language have to constantly be accused of not caring about memory safety which is hardly the truth.
- throwawaymaths 1y ago
  because it gets it out of the fast path compile cycle. do you need a borrow checker for `ls`? Probably not. don't use it. do you need it every time you work through intermediate ideas in a refactor? probably not. just turn it on in CI.
  - steveklabnik 1y ago
    The borrow checker is very fast.
    - throwawaymaths 1y ago
      computationally. But it slows down the programmer. It is not a zero-cost human operation. If it were, we wouldn't need computers to do it.
      - steveklabnik 1y ago
        I don’t think it slows me down, it speeds me up. It’s well known that surfacing issues earlier in a process saves time compared to later in a process.
  - alpaca128 1y ago
    The borrow checker is not the slow part of the Rust compiler and lets me avoid bugs, why would I not always want to use it? And if you put the borrow checker in the CI you massively increased the latency between writing the code and getting all relevant feedback from the compiler/tooling. This would do the opposite of what you intended.
    - throwawaymaths 1y ago
      You don't have to query all checks at all times. You only have to borrow check when you pr to main. What is the sum latency of the coder dealing with conceptual problem of satisfying the borrow checker at every stage during an arduous refactor where they don't fully have the destination model in mind (and might want to try things out only to discard them). Versus, just ignoring it, seeing how the chips fall, and fixing ownership errors in one or two passes at the end once you've settled om the code structure? Of course you don't have to take the full round trip-to-someone-else's-computer latency either. If you can run it in CI, I presume you could run it locally too, and borrow checking is not particularly slow for the computer. You're also not (because one can't) quantifying the problem of a developer getting exasperated and saying, fuck it, it passes the borrow checker, good enough, instead of actually taking the time to make their code legible first and then making sure it is memory safe. This absolutely happens.
tialaramex 1y ago
"But seatbelts would also work if everybody was just choosing to use them rather than us mandating their fitment and use, so I don't understand why facts are true" Amusingly this is even true for the linter, nobody ran the C linter, more or less everybody runs the Rust linter, the resulting improvement in code quality is everything you'd hope. All humans love to believe they're above average, most are not and average is by definition a mediocre aspiration. Do better.
- throwawaymaths 1y ago
  what the hell are you talking about. if you are writing security conscious software you should turn on a static checker and proudly show a badge that says "this code is memory safe". if youre writing a custom data pipeline to be used in a niche scientific field where the consumers are you and anyone that wants to repro your pipeline, and everything is in arenas, who the fuck cares. don't bother with static analysis.
  - josephg 1y ago
    If everything is in arenas, lifetimes get much easier. But, the borrow checker doesn't just check lifetimes. It also checks ownership, and that variables either have a single mutable reference or immutable references. The optimizer assumes those invariants are maintained in the code. Many of its optimizations wouldn't be sound otherwise. So, if you could compile code which fails the borrow checker, there's all sorts of weird and wonderful sources of UB eagerly waiting to give you a really bad day - from aliasing issues to thread safety problems to use-after-free bugs. The borrow checker has been around forever in rust. So I don't think anyone has any idea what the implications would be of compiling "bad" code.
    - throwawaymaths 1y ago
      Point being, there are many many individual programs where none of those things you talk about exist. So why not have a programming system where you can actually turn those things off for development velocity. I'm rejecting the idea that "opt-in" is bad. Opt-out is of course better, but "no choice" is not good.
saagarjha 1y ago
Because you're always going to write some code that the tools can't reason about.
- throwawaymaths 1y ago
  thats true for rust too (hence "unsafe")

There's also no reason to have a separate borrow checker if it could just be integrated in the compiler. When a compiler has a borrow checker that means the language was already designed to enable borrow checking in the first place. And if a language can let you do borrow checking why would you use a separate tool?

josephg 1y ago
Also it’s a great way to make sure every library in the ecosystem passes the borrow checker.
- throwawaymaths 1y ago
  why do you expect compile time static analysis to fail at this? unless youre loading a precompiled asset?
  - josephg 1y ago
    I don't. I think compile time static analysis is great. Upthread you said this: > there's no reason why the borrow checker must be in the compiler proper. On a technical front, I completely agree. But there's an ecosystem benefit to having the borrow checker as part of the compiler. If the borrow checker wasn't in the compiler proper, lots of people would "accidentally forget" to run it. As a result, lots of libraries would end up on crates.io which fail the borrow checker's checks. And that would be a knock on disaster for the ecosystem. But yes, there's nothing stopping you writing a rust compiler without a borrow checker. It wouldn't change the resulting binaries at all.
    - throwawaymaths 1y ago
      > lots of people would "accidentally forget" to run it yeah, like how the sel4 guys accidentally forget to run their static analysis all the time. You put a badge on CI. If you "forget to run" the static analysis, then people get on you for not running it. Or people get on you if you don't have the badge. Just like how people get on people for not writing programs in rust.
      - josephg 1y ago
        Q: If we can get men on the moon, why is my lawnmower such a piece of junk? A: The engineers who got us in to space didn’t design your lawnmower. The SeL4 team won’t forget to run their static analysis checks. But most people aren’t at their level. Most people just want to get on with it. The borrow checker is a pain in the neck to learn - and if it were optional, you better believe lots of people would avoid it forever. I may well have been in that camp too - I found it really hard to get my head around it! If you want a modern C-like language without rust’s borrow checker, Zig or Odin is probably a better bet. They’re both fine languages. > Just like how people get on people for not writing programs in rust. Who? Where?
        throwawaymaths 1y ago
        your argument doesn't hold water, because you are appealing to the existence of a schroedinger's programmer that simultaneously would use rust but also wouldn't turn on a borrow checker if it existed in another language. My point is the fact that people use Rust means that people do care. And those people will run static analysis checks (as long those static analysis checks aren't the shitty or overly difficult to run), and they will notice that your library isn't checked. Or, better yet, they will integrate it into their project, run the checker on their project, find the problem in the lazy person's dependency and PR a fix or fork it if the maintainer is an asshole. Here's the thing. Rust is currently "the only game in town" for spatiotemporal memory safety and that is sucking the air out of the atmosphere, because no one wants to invest time into trying other ideas. And that's a shame, because everyone makes assumptions that Rust must be the only way to do spatiotemporal safety (cough cough Ada/Spark). And it gives cover for people to claim things that are presumptuous and totally untested like our schroedinger's programmer here. Rust has a lot lot lot of shitty things in it, like RAII, and proc macros, and pushing you into some incredibly complicated (and privileged) templated types that are doing some things under the hood (remember when rust switched from jemalloc to malloc?), and Rust hasn't ever gotten to keyword generics yet. Those of us who don't want that kind of BS in our language have to constantly be accused of not caring about memory safety which is hardly the truth.
throwawaymaths 1y ago
because it gets it out of the fast path compile cycle. do you need a borrow checker for `ls`? Probably not. don't use it. do you need it every time you work through intermediate ideas in a refactor? probably not. just turn it on in CI.
- steveklabnik 1y ago
  The borrow checker is very fast.
  - throwawaymaths 1y ago
    computationally. But it slows down the programmer. It is not a zero-cost human operation. If it were, we wouldn't need computers to do it.
    - steveklabnik 1y ago
      I don’t think it slows me down, it speeds me up. It’s well known that surfacing issues earlier in a process saves time compared to later in a process.
- alpaca128 1y ago
  The borrow checker is not the slow part of the Rust compiler and lets me avoid bugs, why would I not always want to use it? And if you put the borrow checker in the CI you massively increased the latency between writing the code and getting all relevant feedback from the compiler/tooling. This would do the opposite of what you intended.
  - throwawaymaths 1y ago
    You don't have to query all checks at all times. You only have to borrow check when you pr to main. What is the sum latency of the coder dealing with conceptual problem of satisfying the borrow checker at every stage during an arduous refactor where they don't fully have the destination model in mind (and might want to try things out only to discard them). Versus, just ignoring it, seeing how the chips fall, and fixing ownership errors in one or two passes at the end once you've settled om the code structure? Of course you don't have to take the full round trip-to-someone-else's-computer latency either. If you can run it in CI, I presume you could run it locally too, and borrow checking is not particularly slow for the computer. You're also not (because one can't) quantifying the problem of a developer getting exasperated and saying, fuck it, it passes the borrow checker, good enough, instead of actually taking the time to make their code legible first and then making sure it is memory safe. This absolutely happens.

tialaramex 1y ago

"But seatbelts would also work if everybody was just choosing to use them rather than us mandating their fitment and use, so I don't understand why facts are true" Amusingly this is even true for the linter, nobody ran the C linter, more or less everybody runs the Rust linter, the resulting improvement in code quality is everything you'd hope. All humans love to believe they're above average, most are not and average is by definition a mediocre aspiration. Do better.

throwawaymaths 1y ago
what the hell are you talking about. if you are writing security conscious software you should turn on a static checker and proudly show a badge that says "this code is memory safe". if youre writing a custom data pipeline to be used in a niche scientific field where the consumers are you and anyone that wants to repro your pipeline, and everything is in arenas, who the fuck cares. don't bother with static analysis.
- josephg 1y ago
  If everything is in arenas, lifetimes get much easier. But, the borrow checker doesn't just check lifetimes. It also checks ownership, and that variables either have a single mutable reference or immutable references. The optimizer assumes those invariants are maintained in the code. Many of its optimizations wouldn't be sound otherwise. So, if you could compile code which fails the borrow checker, there's all sorts of weird and wonderful sources of UB eagerly waiting to give you a really bad day - from aliasing issues to thread safety problems to use-after-free bugs. The borrow checker has been around forever in rust. So I don't think anyone has any idea what the implications would be of compiling "bad" code.
  - throwawaymaths 1y ago
    Point being, there are many many individual programs where none of those things you talk about exist. So why not have a programming system where you can actually turn those things off for development velocity. I'm rejecting the idea that "opt-in" is bad. Opt-out is of course better, but "no choice" is not good.

saagarjha 1y ago

Because you're always going to write some code that the tools can't reason about.

throwawaymaths 1y ago
thats true for rust too (hence "unsafe")