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.
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.
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.
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.
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.
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.
> 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.
I feel like people like OP, who don't understand UB and its consequences, would benefit the most from the strict compiler, but can be bothered the least to learn what it's saying.
I understand what it’s saying. I just disagree that it has to be done for every compilation. Often, as a human, I can reason that it is safe (or reasonably safe for what bug I am attempting to fix). I’m not talking about released software, I’m talking about software I am developing in the moment that I am developing it.
This is exactly the attitude that makes me very happy that the Rust compiler is so strict. The people who need the training wheels most are the same folks who think they don't.
I mean, I fix bugs. Rewriting half the program just to verify the bugs are fixed is overkill before opening a PR (you know, verifying the approach, validating assumptions, manual tests, the stuff you do long before actually fixing the bug, etc). But comments like these and others on this thread is exactly why I may not in the future. This is a rather toxic thread. People seem to treat this thing as a religious artifact without giving a single reason grounded in practical computer science and software engineering.
> But comments like these and others on this thread is exactly why I may not in the future.
Please take your C style memory bugs with you.
In case anyone reading the thread would like quality information about Rust and memory safety, a great place to start is: https://www.youtube.com/@NoBoilerplate
It isn’t about the “after” it’s about the “before”. For example, if I insert some code that divides by zero “later” but causes some new behavior I’m interested in, that’s what I’m interested in. The divide by zero is annoying, but can be addressed later.
If the compiler forced me to check ever integer division wasn’t a divide by zero, that would be annoying in this case. The borrow checker is like this. It forces you to rewrite entire application code just to see if some new behavior fixes a bug, in the name of safety, without realizing that “for just this execution, I don’t care about safety.”
The parent's point is that there is no separation between "before" or "after", it all ends up in the same artifact. And when you write invalid code, you have no guarantees about the compiled artifact anymore.
There is an example of C code (fairly sure I saw it on HN) where violating a UB rule caused an entirely dead piece of code to suddenly be executed, which even made sense after explanation.
In the linked article, Rust-minus-borrow-checker somehow caused an invalid number to appear inside a compile-time static array.
Sure, poke around the results of UB all you want. Curiosity is great. But at some point you'll have to compile your hypothesis as part of valid code, to be able to trust the results.
Thanks for the link! I think I had in mind another one, where the UB fuckery happened at a lower level (I think you ended up with a semicolon/brace effectively "disappearing"?). But that's a good example too.
It's anecdotal, but most of the Rust projects I see posted to Hacker News are new projects. Relatively few are existing C or C++ projects that are trying to port gradually to a new language but those exist too.
That said, there is definitely a class of projects that are aiming to replace popular command-line tools with Rust replacements. In many cases, these offer much of the same functionality, but use Rust to increase parallelization or take advantage of the high performance library ecosystem.
The borrow checker doesn't determine whether a program is valid or not (if by valid you mean safe). It can be proven that doing so is actually imposible. What it does is that it attempts to prove that your program is valid, but will fail unless the proof is trivial, and it never tries to prove that your program is invalid.
The point is that you, the programmer, has intelligence and creativity and can prove that some programs are valid, while the borrow checker wouldn't be able to. So the set of rules you'd follow might be different. This is true, in theory, of many programmers in C++ for example, with the drawback that you might have made a mistake in your proof to yourself.
I'd claim that the Rust philosophy is "the general case is undecidable, but if we restrict the scope to 90% of the cases, we can automate the checks and give you an escape hatch for the remaining 10%". I personally appreciate that approach because the remaining 10% of cases are actually uncommon enough in what I do that I don't have to even think about the problem most of the time.
But that's not actually true. It's very common have to have a program that is valid and won't pass the borrow checker. You need to adjust the way you program to generate programs the borrow checker will approve of, and then the 10% is when it's hard or impossible to make that adjustment.
It's fine, it's just that it is more restrictive than the philosophy claims. It's still a good approach.
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.