4 ms·

> But if you need a linked list, would that be so bad? The answer from a Rust programmers perspective is: yes, it's bad. Rust's secret sauce is if you don't u

> But if you need a linked list, would that be so bad? The answer from a Rust programmers perspective is: yes, it's bad. Rust's secret sauce is if you don't use unsafe, you have a memory safe language. In fact it's better than that. Due to its strong type system "safe Rust" is safer than almost all languages, including Java and the popular interpreted languages like Python, the one notable exception being Ada spark. The problem with this rosy picture is unsafe Rust. It's harder to get right than C (which 100% unsafe), and you can't write a non-trivial Rust program without at least calling unsafe code. That means there is a trade-off going on. If Rust can keep the amount of unsafe code small and bounded, it wins over 100% unsafe C. If it can't, well you may as well use C. Today's Rust does manage to keep unsafe code bounded. Just about any program can be written using purely safe code by using Rusts standard library ("std"). Std itself does contain a high'ish percentage of unsafe code (about 20%), but crucially a programmer using std never needs to use unsafe if they are prepared to make the occasional speed tradeoff (as could have been done in the article). Thus Rust + std + the rule "no unsafe", makes for a perfectly memory safe programming environment. Based on that, a pact has now arisen in the Rust community. You are allowed to write libraries like "std" that use unsafe, but normal usage of those libraries must never require the caller to use unsafe code. The pact ensures unsafe code doesn't spread like a virus, and so Rust will always maintain it's safety advantage over C for your average programmer. But, it's not possible to write an intrusive implementation of a linked list that doesn't required the caller to use unsafe. Therefore, any such library would be ostracised by the Rust community.

steveklabnik 1y ago
This is just not really factual. The intrusive_collections package has five million downloads https://crates.io/crates/intrusive-collections https://crates.io/crates/intrusive-collections Using one when you don't need to would be considered bad, but unsafe exists to be used when necessary. Nobody shuns unsafe code purely for it being unsafe code.
- rstuart4133 1y ago
  Ahh, I stand corrected. It is possible to implement an intrusive collection without making the caller use unsafe. For some uses. For the others he's abstracted the unsafe calls to just cursor_from_ptr and cursor_mut_from_ptr. I suspect they would see heavy use, but he's reduced the safety guarantees you have to prove to the absolute minimum. Colour me impressed. I wish I had thought of that. I might become the 5,243,766 + 1 user. As for this: > Using one when you don't need to would be considered bad, but unsafe exists to be used when necessary. Nobody shuns unsafe code purely for it being unsafe code. Hmmm. You've just contradicted yourself. You've just said if you were given a safe and unsafe implementation of the same thing, you would shun the unsafe version. Than go on to say "Nobody shuns unsafe code purely for it being unsafe code". But if you want a another example, try: https://news.ycombinator.com/item?id=45516255 https://news.ycombinator.com/item?id=45516255. Two of his three reasons are easily solved with unsafe.
  - steveklabnik 1y ago
    > You've just contradicted yourself. No, I did not. It is true that nobody shuns unsafe code for simply being unsafe. Choosing a safe alternative over an unsafe one means that there is an alternative. Unsafe code to do the job that unsafe code is meant to do is totally fine. That’s the reason it exists!

steveklabnik 1y ago

This is just not really factual. The intrusive_collections package has five million downloads https://crates.io/crates/intrusive-collections https://crates.io/crates/intrusive-collections Using one when you don't need to would be considered bad, but unsafe exists to be used when necessary. Nobody shuns unsafe code purely for it being unsafe code.

rstuart4133 1y ago
Ahh, I stand corrected. It is possible to implement an intrusive collection without making the caller use unsafe. For some uses. For the others he's abstracted the unsafe calls to just cursor_from_ptr and cursor_mut_from_ptr. I suspect they would see heavy use, but he's reduced the safety guarantees you have to prove to the absolute minimum. Colour me impressed. I wish I had thought of that. I might become the 5,243,766 + 1 user. As for this: > Using one when you don't need to would be considered bad, but unsafe exists to be used when necessary. Nobody shuns unsafe code purely for it being unsafe code. Hmmm. You've just contradicted yourself. You've just said if you were given a safe and unsafe implementation of the same thing, you would shun the unsafe version. Than go on to say "Nobody shuns unsafe code purely for it being unsafe code". But if you want a another example, try: https://news.ycombinator.com/item?id=45516255 https://news.ycombinator.com/item?id=45516255. Two of his three reasons are easily solved with unsafe.
- steveklabnik 1y ago
  > You've just contradicted yourself. No, I did not. It is true that nobody shuns unsafe code for simply being unsafe. Choosing a safe alternative over an unsafe one means that there is an alternative. Unsafe code to do the job that unsafe code is meant to do is totally fine. That’s the reason it exists!