[throwawaymaths]

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.

[josephg]

> do you need a borrow checker for `ls`? Probably not.

Does ls use references and objects with lifetimes? I bet it does. And if so, the answer is yes. You do need the borrow checker in rust to make sure it uses memory and lifetimes correctly.

If your program somehow doesn’t use references or owned objects, then the borrow checker doesn’t have any work to do. So there’s no harm done in leaving it on.

[alpaca128]

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]

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.

[steveklabnik]

The borrow checker is very fast.

[throwawaymaths]

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]

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.