5 ms·

Not sure at all - I have effectively zero working knowledge of Rust - and certainly not looking to second-guess people's motivations for using the feature. The

Not sure at all - I have effectively zero working knowledge of Rust - and certainly not looking to second-guess people's motivations for using the feature. The big bias I'm working from here is that, as an outsider, I have a hard time reconciling all the big talk about how Rust makes it impossible to experience certain classes of bugs, with the existence of a known set of things that its type checker can't check, and which includes a lot of things that are difficult to avoid. One could be forgiven for thinking that the Rust community has a habit of keeping its fingers crossed behind its back when talking. I don't want to make the perfect the enemy of the good, of course. I realize the feature is there for an important reason. But it sure looks to me like Zig is also good despite being imperfect. Perhaps they're both similarly good languages.

Ar-Curunir 5y ago
No type checker can catch all buggy programs (that involve solving the halting problem). In practice, Rust strikes a good balance: in over 120,000 LoC of Rust code that I have helped write and maintain, we have maybe 10 lines of unsafe, with performance matching or exceeding that of the C/C++ counterparts.
- tialaramex 5y ago
  > No type checker can catch all buggy programs (that involve solving the halting problem). It's far worse than that, the problem is that the machine can't know what was intended. The result 5 from calling sum([1,2,1,1]) makes sense, but alas this function was intended to produce the product not the sum, the inputs were supposed to be [1,2,3,4] and the desired result was 24... the machine can't hope to guess that. A program may be buggy even if it its meaning is transparent and exactly reflects its effect, simply because it doesn't reflect the intention of the person who wrote the wrong program. This quote is attributed to Babbage: 'On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question' But that is what we wanted, even if we obviously can't have it.
not2b 5y ago
Proper use of 'unsafe' in Rust is to write safe code that the compiler cannot prove is safe. In fact, this is done to implement many parts of Rust's standard library. See the split_at_mut example in https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html The spec here is to turn one mutable slice into two non-overlapping mutable slices. The operation does not violate memory safety; we wind up with only one mutable reference to any part of the object. But the compiler does not know how to verify that the programmer has done this correctly. Here, 'unsafe' means 'I certify that this is safe, use that as a lemma to do further checking'.
pjmlp 5y ago
All systems programming languages need the ability to do unsafe stuff, the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. It is a big difference to have it on your face that something might need to be properly double checked and having each line of code as possible security exploit.
- jhgb 5y ago
  > the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. Would you consider Oberon to belong in the former or latter category? On one hand, there's no explicit code blocks as such (syntactically). On the other hand, unsafe primitive operations are limited to the SYSTEM module, so functions calling operations in the SYSTEM module can be considered doing unsafe things.
  - pjmlp 5y ago
    If you read Oberon documentation, modules importing SYSTEM are tainted and considered unsafe. Just like Modula-2 already does it.
    - jhgb 5y ago
      Well...that's what I meant. But which one is it, then?
      - pjmlp 5y ago
        Just like the languages that have unsafe code blocks it is relatively easy to track down unsafe modules, same thing. And just like languages with unsafe code blocks, there are compilers that have switches to forbid the use of tainted modules unless explicitly allowed. In any case, way better than what C, C++ and Objective-C offer, regarding security per line of code.
heavyset_go 5y ago
It might help to better understand the motivations behind unsafe Rust by reading some of The Rustonomicon[1]. [1] https://doc.rust-lang.org/nomicon/ https://doc.rust-lang.org/nomicon/

Ar-Curunir 5y ago

No type checker can catch all buggy programs (that involve solving the halting problem). In practice, Rust strikes a good balance: in over 120,000 LoC of Rust code that I have helped write and maintain, we have maybe 10 lines of unsafe, with performance matching or exceeding that of the C/C++ counterparts.

tialaramex 5y ago
> No type checker can catch all buggy programs (that involve solving the halting problem). It's far worse than that, the problem is that the machine can't know what was intended. The result 5 from calling sum([1,2,1,1]) makes sense, but alas this function was intended to produce the product not the sum, the inputs were supposed to be [1,2,3,4] and the desired result was 24... the machine can't hope to guess that. A program may be buggy even if it its meaning is transparent and exactly reflects its effect, simply because it doesn't reflect the intention of the person who wrote the wrong program. This quote is attributed to Babbage: 'On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question' But that is what we wanted, even if we obviously can't have it.

not2b 5y ago

Proper use of 'unsafe' in Rust is to write safe code that the compiler cannot prove is safe. In fact, this is done to implement many parts of Rust's standard library. See the split_at_mut example in https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html The spec here is to turn one mutable slice into two non-overlapping mutable slices. The operation does not violate memory safety; we wind up with only one mutable reference to any part of the object. But the compiler does not know how to verify that the programmer has done this correctly. Here, 'unsafe' means 'I certify that this is safe, use that as a lemma to do further checking'.

pjmlp 5y ago

All systems programming languages need the ability to do unsafe stuff, the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. It is a big difference to have it on your face that something might need to be properly double checked and having each line of code as possible security exploit.

jhgb 5y ago
> the big difference between C , C++, Objective-C and all the remaining system programming languages since JOVIAL and NEWP, is the explicit unsafe code blocks that make that visible. Would you consider Oberon to belong in the former or latter category? On one hand, there's no explicit code blocks as such (syntactically). On the other hand, unsafe primitive operations are limited to the SYSTEM module, so functions calling operations in the SYSTEM module can be considered doing unsafe things.
- pjmlp 5y ago
  If you read Oberon documentation, modules importing SYSTEM are tainted and considered unsafe. Just like Modula-2 already does it.
  - jhgb 5y ago
    Well...that's what I meant. But which one is it, then?
    - pjmlp 5y ago
      Just like the languages that have unsafe code blocks it is relatively easy to track down unsafe modules, same thing. And just like languages with unsafe code blocks, there are compilers that have switches to forbid the use of tainted modules unless explicitly allowed. In any case, way better than what C, C++ and Objective-C offer, regarding security per line of code.

heavyset_go 5y ago

It might help to better understand the motivations behind unsafe Rust by reading some of The Rustonomicon[1]. [1] https://doc.rust-lang.org/nomicon/ https://doc.rust-lang.org/nomicon/