3 ms·

> This is a fundamental misunderstanding of how "unsafe" code relates to a platform's trusted computing base. Rust could move all of those unsafe data structure

• kibwen 3mo ago
  > No, you're missing the point, which is that you cannot write some common data structures in safe Rust (whether they're implemented in the standard library or in the compiler), but you can in Java (inside or outside the standard library). In other words, the point is that safe Rust is quite restricted. 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. You highly underestimate what safe Rust can do; it's not "quite restricted", this is a low-information take. > In Rust, that base has to be extended to any third-party code that uses unsafe, which is needed in many more situations. 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. > It isn't controversial that the amount of stuff you can do in safe Java is significantly higher than the amount of stuff you can do in safe Rust. That's just obvious. Turns out, things that people take as obvious can also be wrong.
  • pron 3mo ago
    > 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.
    • vlovich123 3mo ago
      > Of course you can, but the reason you don't is that their performance would be quite bad Not very different from Java or C#. Worse than zig/c/c++ but that’s because those are the equivalent of using use in rust.
      • pron 3mo ago
        > Not very different from Java or C# It will be significantly worse than Java, at least in some important situations (don't know about C#). I've been programming in C++ for many, many years, and I find it increasingly hard to even match Java's performance, even when writing unsafe code, especially when programs get larger and/or more concurrent (very broadly speaking, Java's performance is about that of C++ - in some situations it's worse and in others is better, but the same general vicinity; after all, the JVM was designed to address some of the performance issues that certain classes of C++ programs suffer from). Performance is not the reason to use a low-level language in many domains, and in those domains, if you want super-high performance and safety, there are better and more popular alternatives already. You use a low-level language when you need the things low-level languages do best, but you also expect performance that is more-or-less the same as the high-performance safe alternatives.