> This is incorrect. You can write those data structures in safe Rust just as easily as you can in Java. You'd write them using the safe primitives that the Rus

> This is incorrect. You can write those data structures in safe Rust just as easily as you can in Java. You'd write them using the safe primitives that the Rust stdlib provides to you, just like how Java does it. Such collections could often be made to have superior performance by using unsafe Rust, which is why the collections in the stdlib use unsafe code internally, but it's an optimization, not a requirement. Of course you can, but the reason you don't is that their performance would be quite bad. I guess you could call that "an optimisation", but good performance for these data structures is a requirement. I am well aware that you can do a lot in safe Rust, but the result is such that you wouldn't want to use Rust at all. > That Rust allows you to define your own safe interfaces to unsafe constructs is a strength of Rust, and necessary for any language that wants to challenge C and C++ on the basis of runtime performance. Every language with unsafe constructs allows you to do that! The problem is that with Rust you need to do it quite a bit (of course, if you want acceptable performance, that is). That's not an upside of Rust compared to other safe languages, it's a downside. > Turns out, things that people take as obvious can also be wrong. They can, but this one isn't. Safe Rust is Turing complete and in the functional sense you could do anything with it. But the same is true for Python. So does that mean safe Rust and Python are interchangeable because by your measure they can do the same things? Of course not.