Turning off Rust's borrow checker completely (2022) • Hacker News Board

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

#61

Post by [deleted] » Tue, Jan 23, 2024, 8:27 PM UTC

timschmidt wrote: post #60

withinboredom wrote: post #58

Earlier quoted context omitted.

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

[deleted]

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

#62

Post by sudosysgen » Tue, Jan 23, 2024, 9:15 PM UTC

estebank wrote: post #59

sudosysgen wrote: post #14

Earlier quoted context omitted.

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.

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.

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

#63

Post by nickm12 » Thu, Feb 01, 2024, 7:47 AM UTC

withinboredom wrote: post #13

nickm12 wrote: post #12

Earlier quoted context omitted.

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

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

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.