> 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 structures out of the standard library and into the compiler itself, thereby reducing the amount of occurrences of the string "unsafe" in the source, code, but this would do nothing to reduce the size of the trusted computing base that Rust presents.

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.

> Java's own data structures are implemented with the support of an extensive runtime written in C++, which forms their own trusted computing base that every user of Java relies upon, and demands just as much careful auditing as any data structure in the Rust standard library.

No, because these data structures are not part of the trusted computing base, which is fixed and closed. In Rust, that base has to be extended to any third-party code that uses unsafe, which is needed in many more situations. In fact, the need for unsafe code in Java has been so reduced that we're currently in the process of removing Unsafe altogether, making it inaccessible to third party code, which would still be able to write the data structures that would be unsafe in Rust in safe Java (the only unsafe thing remaining would be the FFM API, used for FFI, and the legacy JNI, used for that same purpose).

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.

The point is not that those specific implementations use unsafe Rust but to illustrate that to write even basic data structures you need unsafe Rust.