3 ms·

The point the OP was trying to convey (and the OP could have been clearer) is that Rust will allow you to button up an unsafe core behind a completely safe inte

The point the OP was trying to convey (and the OP could have been clearer) is that Rust will allow you to button up an unsafe core behind a completely safe interface. That is, no use of the safe interface could ever possibly lead to memory unsafety, and this is checked by the compiler. A core value proposition of Rust is not necessarily that you will never need to utter `unsafe`, but rather, you can build safe abstractions on top of `unsafe`.

jstimpfle 10y ago
That's not the reason why C/C++ code that uses a linked list is "unsafe". It's "unsafe" because it doesn't protect the use. In other words, because the client code is itself "unsafe". If the use was protected (whether dynamically with a lock or statically by some Rust-like language extension, I don't care), there was no more of an issue than in Rust. And if the linked list is itself broken, Rust can't help you either. So I still don't see a causal relationship. Is it because I'm drunk?
wuch 10y ago
While hiding unsafe parts of code behind safe interface works great in Rust, especially that ownership / borrowing rules expresses much more than is possible in other mainstream languages (in Java you wouldn't know if you are the owner of collection returned collection, or maybe it just a view, etc.), there is one thing that I never seen addressed in this kind of arguments: Writing unsafe code in Rust is harder than doing it in C/C++, because Rust introduces a whole new class of undefined behaviours that is just absent from C/C++. See [0], [1] or [2] in general for examples. [0] http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsafe-code-and-shared-references/ http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa... [1] http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-tootsie-pop-model-for-unsafe-code/ http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-... [2] https://github.com/nikomatsakis/rust-memory-model https://github.com/nikomatsakis/rust-memory-model
- burntsushi 10y ago
  Yes, it can be tricky. One of the problems is that we don't have the memory model completely worked out. I don't know how much harder it is than C/C++ though. Seems hard to quantify. But the `unsafe` markers should help quite a bit.
- notriddle 10y ago
  There are a bunch of things that are UB in C and C++ that are well-defined in Rust. * Signed integer overflow * Aliased pointers to different types (-fno-strict-alias) * Probably more, but the formalised memory model is still up in the air. The ones I just listed are just the ones that are already decided...
  - wuch 10y ago
    True, in fact undefined-behaviour-wise I don't think there is any mainstream language that comes close in this respect to C/C++. Alas, this is well-known and addressed in various publications. Converse, things that could be eventually decided to be UB in Rust, but are not UB in C/C++, is rarely mentioned at all. It is quite interesting what is cost (in terms of UB behaviour) of making various optimization that are claimed to be possible in Rust but not yet realized. Reading through some of Niko proposals it would seems that this cost is quite nontrivial.

jstimpfle 10y ago

That's not the reason why C/C++ code that uses a linked list is "unsafe". It's "unsafe" because it doesn't protect the use. In other words, because the client code is itself "unsafe". If the use was protected (whether dynamically with a lock or statically by some Rust-like language extension, I don't care), there was no more of an issue than in Rust. And if the linked list is itself broken, Rust can't help you either. So I still don't see a causal relationship. Is it because I'm drunk?

wuch 10y ago

While hiding unsafe parts of code behind safe interface works great in Rust, especially that ownership / borrowing rules expresses much more than is possible in other mainstream languages (in Java you wouldn't know if you are the owner of collection returned collection, or maybe it just a view, etc.), there is one thing that I never seen addressed in this kind of arguments: Writing unsafe code in Rust is harder than doing it in C/C++, because Rust introduces a whole new class of undefined behaviours that is just absent from C/C++. See [0], [1] or [2] in general for examples. [0] http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsafe-code-and-shared-references/ http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa... [1] http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-tootsie-pop-model-for-unsafe-code/ http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-... [2] https://github.com/nikomatsakis/rust-memory-model https://github.com/nikomatsakis/rust-memory-model

burntsushi 10y ago
Yes, it can be tricky. One of the problems is that we don't have the memory model completely worked out. I don't know how much harder it is than C/C++ though. Seems hard to quantify. But the `unsafe` markers should help quite a bit.
notriddle 10y ago
There are a bunch of things that are UB in C and C++ that are well-defined in Rust. * Signed integer overflow * Aliased pointers to different types (-fno-strict-alias) * Probably more, but the formalised memory model is still up in the air. The ones I just listed are just the ones that are already decided...
- wuch 10y ago
  True, in fact undefined-behaviour-wise I don't think there is any mainstream language that comes close in this respect to C/C++. Alas, this is well-known and addressed in various publications. Converse, things that could be eventually decided to be UB in Rust, but are not UB in C/C++, is rarely mentioned at all. It is quite interesting what is cost (in terms of UB behaviour) of making various optimization that are claimed to be possible in Rust but not yet realized. Reading through some of Niko proposals it would seems that this cost is quite nontrivial.