4 ms·

Wait, what? Unsafe in Rust _is_ the actual benefit. That is to say, what `unsafe` does is that it allows you to implement a fundamentally tricky thing and expre

Wait, what? Unsafe in Rust _is_ the actual benefit. That is to say, what `unsafe` does is that it allows you to implement a fundamentally tricky thing and express its safety invariants in the type system and lifetime system, resulting in a safe API with no tricky parts. That's the whole point. There's tons of trivial unsafe in the Rust ecosystem, and a little bit of nontrivial unsafe, because crates.io is full of libraries doing interesting things (high-performance data structures, synchronization primitives, FFI bindings, etc.) while providing a safe API, so you can do all of that without writing any unsafe yourself. The point of Rust isn't that you can implement low-level data structures in safe code, but that you can use them without fear.

pizlonator 2y ago
Saying that unsafe is a benefit is backwards, I think. Unsafe is the compromise Rust made to achieve its other goals, but of course Rust would be better if there was some way of doing things without unsafe.
- not2b 2y ago
  Consider the split_at_mut function. It takes one mutable slice, and returns two mutable slices by chopping at a caller-specified point. It's in the standard library. The operation is completely safe, as after the call the original mutable slice is no longer live, but the borrow checker won't let you write such a function yourself unless you tag it as unsafe, so that's what the implementation must do. The same thing happens in the implementation of Vec: there is low-level code that is unsafe, used to provide safe abstractions.
  - pizlonator 2y ago
    That’s not a benefit of Rust. In other safe languages you could implement those things without writing a single bit of unsafe code. (This is true in Fil-C for example.)
    - amluto 2y ago
      Is that really fair? Neither Fil-C nor C have anything that particularly resembles & or &mut. If Rust had an &shared_mut style of reference, you could presumably split it without unsafe. For that matter, Rust does have various interior-mutable types, and you could have a shared reference to a slice of AtomicBool or whatever, and you can split that without any particular magic.
      - pizlonator 2y ago
        Fil-C doesn’t have those things because it doesn’t need them to achieve safety.
        Dylan16807 2y ago
        How does it make sure data races are safe? Rust can split up an array without unsafe if you use Rc. That has overhead, but is it more than Fil-C in this situation?
        pizlonator 2y ago
        Data races are memory safe in Fil-C.
        amluto 2y ago
        I think the disconnect here is that some people want their data races (a) not to result in memory safety violations; some people want them to also (b) not result in nonsensical control flow or code producing results that look impossible, and some people want (c) data races to simply not occur. You seem to like (a), Linus Torvalds seems to like (b), and Rust targets (c).
        pizlonator 2y ago
        Rust doesn’t target (c). That’s a hugely disingenuous claim. The truth is: Rust’s approach to memory safety only works if you also have no data races. This makes it a strictly inferior approach to memory safety, since programs sometimes do have to race (sometimes it’s just the best solution). So, Rust has data race prevention not because it’s a good idea but because the whole language falls apart without it.
  - jeffrallen 2y ago
    I don't see the interest in split_at_mut. I can get the same thing by reslicing in Go. And also the GC will do the job the borrow checker foists off onto the unlucky Rust programmer. Pfft, whatever. Rusters gonna rust, I guess.
    - not2b 2y ago
      I'm not a Ruster, I've spent my career writing a ton of C++. But I'm interested in Rust as an alternative because it doesn't need GC. But in this case, it's not just the memory safety I'm interested in, it's the data races. If we have multiple threads but can guarantee that any object either has only read-only references, or one mutable references and no readers, we don't have data race issues.

pizlonator 2y ago

Saying that unsafe is a benefit is backwards, I think. Unsafe is the compromise Rust made to achieve its other goals, but of course Rust would be better if there was some way of doing things without unsafe.

not2b 2y ago
Consider the split_at_mut function. It takes one mutable slice, and returns two mutable slices by chopping at a caller-specified point. It's in the standard library. The operation is completely safe, as after the call the original mutable slice is no longer live, but the borrow checker won't let you write such a function yourself unless you tag it as unsafe, so that's what the implementation must do. The same thing happens in the implementation of Vec: there is low-level code that is unsafe, used to provide safe abstractions.
- pizlonator 2y ago
  That’s not a benefit of Rust. In other safe languages you could implement those things without writing a single bit of unsafe code. (This is true in Fil-C for example.)
  - amluto 2y ago
    Is that really fair? Neither Fil-C nor C have anything that particularly resembles & or &mut. If Rust had an &shared_mut style of reference, you could presumably split it without unsafe. For that matter, Rust does have various interior-mutable types, and you could have a shared reference to a slice of AtomicBool or whatever, and you can split that without any particular magic.
    - pizlonator 2y ago
      Fil-C doesn’t have those things because it doesn’t need them to achieve safety.
      - Dylan16807 2y ago
        How does it make sure data races are safe? Rust can split up an array without unsafe if you use Rc. That has overhead, but is it more than Fil-C in this situation?
        pizlonator 2y ago
        Data races are memory safe in Fil-C.
        amluto 2y ago
        I think the disconnect here is that some people want their data races (a) not to result in memory safety violations; some people want them to also (b) not result in nonsensical control flow or code producing results that look impossible, and some people want (c) data races to simply not occur. You seem to like (a), Linus Torvalds seems to like (b), and Rust targets (c).
        pizlonator 2y ago
        Rust doesn’t target (c). That’s a hugely disingenuous claim. The truth is: Rust’s approach to memory safety only works if you also have no data races. This makes it a strictly inferior approach to memory safety, since programs sometimes do have to race (sometimes it’s just the best solution). So, Rust has data race prevention not because it’s a good idea but because the whole language falls apart without it.
- jeffrallen 2y ago
  I don't see the interest in split_at_mut. I can get the same thing by reslicing in Go. And also the GC will do the job the borrow checker foists off onto the unlucky Rust programmer. Pfft, whatever. Rusters gonna rust, I guess.
  - not2b 2y ago
    I'm not a Ruster, I've spent my career writing a ton of C++. But I'm interested in Rust as an alternative because it doesn't need GC. But in this case, it's not just the memory safety I'm interested in, it's the data races. If we have multiple threads but can guarantee that any object either has only read-only references, or one mutable references and no readers, we don't have data race issues.