4 ms·

* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase I have seen this

by sai_c 6y ago

* unsafe makes it very easy for you to audit where data races or memory errors are possible, instead of needing to audit an entire c codebase I have seen this argument a couple of times before. But I can't make myself buy it. Because I always have to think about embedded systems in the car industry. Look at this list: https://betterembsw.blogspot.com/2018/09/potentially-deadly-automotive-software.html https://betterembsw.blogspot.com/2018/09/potentially-deadly-... The argument is basically "the possible fail places are easily grepable", right? I said in another comment in this thread (jokingly) "time is money". It seems for the devs in the car industry this saying is of utter most importance. So how does Rust prevent something like this throughout the code base (and those are BIG code bases): "LOL. I need to get this done. unsafe { ... } "

baq 6y ago
it doesn't. if such code passes peer review, it's their problem. you absolutely need buy-in from devs that the borrow checker is there to help you and save time for your future self.
steveklabnik 6y ago
> So how does Rust prevent something like this throughout the code base In some sense, it doesn't. But in another sense, you can't just throw unsafe around things. Unsafe doesn't turn off checks. Unsafe adds new unchecked constructs. This means you can't have written a bunch of code, run into errors, and just toss unsafe {} around it. You'd have to actually re-write it with unsafe constructs in the first place. You can very much do that, if you want. But it's not a trivial escape hatch.
- sai_c 6y ago
  I understand the "unsafe" construct on the technical level, but thanks for clarification nevertheless. My point was that, with "unsafe", Rust provides a technical construct which allows to carry over some negative development styles, possible in the C(++) world, without friction (if wanted). And from the list I linked, there seems to be a lot of momentum for this kind of behaviour in certain industries. You'd have to actually re-write it with unsafe constructs in the first place. This is what I think would happen, and tried to describe. Someone trying to implement a feature, failing with safe mode and resorting to "unsafe" from scratch, just to get it done. So it stays the way it is, i.e. I can't buy the "possible fail places are easily grepable" argument.
  - steveklabnik 6y ago
    Yes, in theory that could happen. In practice, we don’t see it happening. Doesn’t mean it can’t, but time will tell.

by sai_c 6y ago

baq 6y ago

it doesn't. if such code passes peer review, it's their problem. you absolutely need buy-in from devs that the borrow checker is there to help you and save time for your future self.

steveklabnik 6y ago

> So how does Rust prevent something like this throughout the code base In some sense, it doesn't. But in another sense, you can't just throw unsafe around things. Unsafe doesn't turn off checks. Unsafe adds new unchecked constructs. This means you can't have written a bunch of code, run into errors, and just toss unsafe {} around it. You'd have to actually re-write it with unsafe constructs in the first place. You can very much do that, if you want. But it's not a trivial escape hatch.

sai_c 6y ago
I understand the "unsafe" construct on the technical level, but thanks for clarification nevertheless. My point was that, with "unsafe", Rust provides a technical construct which allows to carry over some negative development styles, possible in the C(++) world, without friction (if wanted). And from the list I linked, there seems to be a lot of momentum for this kind of behaviour in certain industries. You'd have to actually re-write it with unsafe constructs in the first place. This is what I think would happen, and tried to describe. Someone trying to implement a feature, failing with safe mode and resorting to "unsafe" from scratch, just to get it done. So it stays the way it is, i.e. I can't buy the "possible fail places are easily grepable" argument.
- steveklabnik 6y ago
  Yes, in theory that could happen. In practice, we don’t see it happening. Doesn’t mean it can’t, but time will tell.