I think he means "unsafe" in the sense of Rust's 'unsafe' keyword, which allows you work with pointers just you normally would in C++. It doesn't mean all C++ is broken! Just that all C++ code has the right to use pointers or invoke undefined behavior without getting smacked down by the compiler.
He clearly states that code which depends on a linked list implementation is "unsafe" for that very reason.
To me that's not convincing argumentation. If code depends on a broken "unsafe" linked list implementation, that's bad no matter what language the code is.
What you say is true under some interpretation of "unsafe", but it doesn't relate with a broken "unsafe" linked list implementation.
Btw. since I'm not a Rust user I might miss something here. And I admit my post was a little short and thus maybe provoking. But just to let everybody know, I got at least 5 downvotes.
Given that answers to my post don't even see that OP implied a causal relationship, that doesn't help with my perception of the "Rust echo chamber on HN" (not my wording).
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`.
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.
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...
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.
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?
In the rust world "unsafe" is synonymous with "isn't proven to be safe by the compiler". Under this definition, every C/C++ program that uses pointers is "unsafe" because the languages make no memory safety guarantees.
unique_ptr is unfortunately still unsafe (in the Rust sense): there's nothing in the language stopping use-after-move of the unique_ptr value itself (which is a null-dereference and undefined behaviour), nor references to the interior becoming dangling.
Owned data in Rust (which is all data by default, unlike C++ which must opt-in via unique_ptr) has stronger guarantees than those provided by unique_ptr. It's still possible to deref a unique_ptr after using std::move.
That may be technically true but in practice and rhetoric "unsafe" is often used in contexts with much broader, implicit connotations. For example, putting Rust-compiler-proven-safety as the top, first, or best feature to consider. In that context, saying "C++ isn't Rust-safe" is essentially defining Rust to be "better", not advancing a coherent argument that it is in fact better.
Given that in unsafe block you still have to uphold the same invariants as in
other blocks of code, your job is actually much harder in Rust that it is in
C/C++.
Take a look at examples in [0], they would be perfectly valid in C/C++, but are
potentially considered undefined behaviour in Rust.
I stopped reading here.