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.

[0] http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa...

[1] http://smallcultfollowing.com/babysteps/blog/2016/05/27/the-...

[2] https://github.com/nikomatsakis/rust-memory-model

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.

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?