3 ms·

> Safety doesn't just come from language features, it also comes from the language disallowing dangerous actions. Rust's unsafe mode opens the door to undefine

> Safety doesn't just come from language features, it also comes from the language disallowing dangerous actions. Rust's unsafe mode opens the door to undefined behaviour, of the sort that plagues so many C/C++ codebases (buffer overflows etc). A program written in safe Rust offers far better assurances than a program making heavy use of unsafe Rust: safe Rust is unable to result in undefined behaviour. Safety is not an absolute, it's a spectrum. No one denies that safe rust is better than unsafe rust on the safety scale. > You may be right that a program written in 100% unsafe Rust might still be less prone to undefined behavior than a program written in C, but that's not my point. Excessive use of unsafe features undermines the considerable safety advantages that Rust offers over C, and it's regrettable when this is disregarded. It's not disregarded. The point you are disregarding that when porting a C application to rust, unsafe rust is a step up from C, not step down from safe rust. Unless you choose to rewrite from ground up (which is infeasible in many places), you'll need unsafe rust, either for binding or by using tooling that converts the C sources to rust. But once you have unsafe rust, you already get all the help that the borrow checker brings and you can gradually shrink the unsafe code. It's a matter of practicality, you seem to be advocating for absolutes and I think that's earning you the down votes you're receiving.

MaxBarraclough 6y ago
> Safety is not an absolute, it's a spectrum. Use of the safe subset of Rust means the compiler and standard-library offer you a guarantee of the absence of undefined behaviour. That's an absolute guarantee of safety, under Rust's understanding of the word. It doesn't give you a guaranteed absence of memory-leaks. It certainly doesn't give you a guarantee of whole-program correctness, as Rust isn't a formal verification framework. Both these properties are beyond the scope of 'safety' as Rust uses it. > It's not disregarded. It is. Projects are described as written in Rust, treating safe Rust and unsafe Rust equally. > The point you are disregarding that when porting a C application to rust, unsafe rust is a step up from C, not step down from safe rust. I explicitly acknowledged this. > Unless you choose to rewrite from ground up (which is infeasible in many places), you'll need unsafe rust, either for binding or by using tooling that converts the C sources to rust. Sure, no disagreement there. > But once you have unsafe rust, you already get all the help that the borrow checker brings and you can gradually shrink the unsafe code. Sure, and that's a good use of Rust's unsafe features. > you seem to be advocating for absolutes Not really. If I had meant to argue that Rust shouldn't have unsafe features, I'd have done so. In an ideal world all code would be written in a way that completely closes the door on undefined behaviour, but we agree there are good reasons Rust includes its unsafe features, and there are good practical reasons to use them. I'm advocating for a greater emphasis on the use of the safe subset of Rust. Written in Rust tells me something about the software. Written in 100% safe Rust tells me much more about the software. That's essentially my point. This distinction doesn't arise with languages like C and JavaScript. All C is unsafe, and all JavaScript is safe. For languages like Rust and D, there's value in being upfront about the use of their safe subsets.

MaxBarraclough 6y ago

> Safety is not an absolute, it's a spectrum. Use of the safe subset of Rust means the compiler and standard-library offer you a guarantee of the absence of undefined behaviour. That's an absolute guarantee of safety, under Rust's understanding of the word. It doesn't give you a guaranteed absence of memory-leaks. It certainly doesn't give you a guarantee of whole-program correctness, as Rust isn't a formal verification framework. Both these properties are beyond the scope of 'safety' as Rust uses it. > It's not disregarded. It is. Projects are described as written in Rust, treating safe Rust and unsafe Rust equally. > The point you are disregarding that when porting a C application to rust, unsafe rust is a step up from C, not step down from safe rust. I explicitly acknowledged this. > Unless you choose to rewrite from ground up (which is infeasible in many places), you'll need unsafe rust, either for binding or by using tooling that converts the C sources to rust. Sure, no disagreement there. > But once you have unsafe rust, you already get all the help that the borrow checker brings and you can gradually shrink the unsafe code. Sure, and that's a good use of Rust's unsafe features. > you seem to be advocating for absolutes Not really. If I had meant to argue that Rust shouldn't have unsafe features, I'd have done so. In an ideal world all code would be written in a way that completely closes the door on undefined behaviour, but we agree there are good reasons Rust includes its unsafe features, and there are good practical reasons to use them. I'm advocating for a greater emphasis on the use of the safe subset of Rust. Written in Rust tells me something about the software. Written in 100% safe Rust tells me much more about the software. That's essentially my point. This distinction doesn't arise with languages like C and JavaScript. All C is unsafe, and all JavaScript is safe. For languages like Rust and D, there's value in being upfront about the use of their safe subsets.