Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turning off Rust's borrow checker completely (2022)

iter.ca

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Turning off Rust's borrow checker completely (2022)

#51

Post by piaste »

dtn wrote: post #49
piaste wrote: post #36

Earlier quoted context omitted.

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,…

I think you're referring to this one: https://blog.tchatzigiannakis.com/undefined-behavior-can-lit... Bonus read: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...

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.

Re: Turning off Rust's borrow checker completely (2022)

#52

Post by timschmidt »

gkbrk wrote: post #48
timschmidt wrote: post #33

Earlier quoted context omitted.

How quickly can you verify the memory safety of that C program in addition to compiling it though? When comparing like to like, C no longer looks so fast.

Rust code with unsafe still compiles slowly. And safe subsets of C still compile quickly.

That is exactly the opposite of my experience.

Re: Turning off Rust's borrow checker completely (2022)

#53

Post by timschmidt »

withinboredom wrote: post #37
timschmidt wrote: post #34

Earlier quoted context omitted.

> as a human, I can reason that it is safe This assumption has been tested at societal scale and proven false, at great cost.

I didn’t say I could do it successfully or that it even matters. Only that I am able to and execute, at my own discretion. You know, have agency.

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.

Re: Turning off Rust's borrow checker completely (2022)

#54

Post by zamalek »

olvy0 wrote: post #45
needlesslygrim wrote: post #40

Earlier quoted context omitted.

You're mostly correct, it is moved into the function (pass by value), and then, at the end of the function's scope, the destructor is called automatically (as the compiler inserts a call to `drop()` at the end of the function) which de-allocates the vec, causing the reference obtained in `main()` become a dangling pointer.

Thank you!

An alternative, more correct but less interesting, explanation: you really need to look at the disassembly (with your specific build of the Rust compiler with the same flags) to see what's really happening. This is why UB (undefined behavior) is dangerous.

For example, the compiler could decide that the entire allocation is unnecessary and elide it, if it's known that the Vec is very small. The compiler could also decide to pass it by ref. Remember that the compiler merely has to preserve your intent, beyond that it is allowed to do whatever it pleases.

https://rust.godbolt.org/

Re: Turning off Rust's borrow checker completely (2022)

#55

Post by markusde »

miki123211 wrote: post #46

I wonder if you could actually write a compiler that does this for compilation speed. Have one mode where the compiler is super fast, has no error checking and can compile some malformed programs, and another mode where the compiler does all the checks. This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes…

Yes... Rust!

I don't know if you can toggle it from the front-end, but the Polonius borrow checker includes a "location insensitive" mode which is faster but accepts fewer programs.

Re: Turning off Rust's borrow checker completely (2022)

#56

Post by gloryjulio »

eropple wrote: post #47
miki123211 wrote: post #46

I wonder if you could actually write a compiler that does this for compilation speed. Have one mode where the compiler is super fast, has no error checking and can compile some malformed programs, and another mode where the compiler does all the checks. This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes…

> This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes that check for them are just pure and unnecessary overhead. It's not an identical case, but TypeScript offers this with `skipLibCheck`. Most people use it. It's generally good--until it's really not good and you eat half a day unwinding a deceptively b…

Sounds like if the code is in JavaScript, it would be already broken anyway

Re: Turning off Rust's borrow checker completely (2022)

#57

Post by estebank »

markusde wrote: post #55
miki123211 wrote: post #46

I wonder if you could actually write a compiler that does this for compilation speed. Have one mode where the compiler is super fast, has no error checking and can compile some malformed programs, and another mode where the compiler does all the checks. This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes…

Yes... Rust! I don't know if you can toggle it from the front-end, but the Polonius borrow checker includes a "location insensitive" mode which is faster but accepts fewer programs.

I think the GP had something else in mind. You're mentioning a mode where the rules are more stringent, allowing for a faster check and consequently faster compile times. The GP is pictuting a mode where the checks are skipped altogether, only the necessary transformations occur with an assumption that everything is already correct. I'm weary of having something like that outside of nightly, unless cargo publish had more checks than it does today.

Re: Turning off Rust's borrow checker completely (2022)

#58

Post by withinboredom »

timschmidt wrote: post #53
withinboredom wrote: post #37

Earlier quoted context omitted.

I didn’t say I could do it successfully or that it even matters. Only that I am able to and execute, at my own discretion. You know, have agency.

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.

Re: Turning off Rust's borrow checker completely (2022)

#59

Post by estebank »

sudosysgen wrote: post #14
pests wrote: post #8

Earlier quoted context omitted.

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 withou…

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…

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.

Re: Turning off Rust's borrow checker completely (2022)

#60

Post by timschmidt »

withinboredom wrote: post #58
timschmidt wrote: post #53

Earlier quoted context omitted.

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 artifa…

> 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

Post reply on HN