[steveklabnik]

Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026.

> Memory safety is necessary, but not sufficient,

I fully agree!

[maybebug]

> I fully agree!

But why then did you conflate safety and memory safety?

> Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026.

No, there is a lot of unsafe in both Rust's standard library and in non-standard Rust libraries for multiple reasons, in particular performance for both kinds (std and user/non-std) of libraries. Thus, as I pointed out, for Rust, "unsafe" is in practice often needed for performance in Rust.

[whytevuhuni]

> "unsafe" is in practice often needed for performance in Rust

That's the power of Rust, not a limitation of it. Rust thrives on its ability to provide safe interfaces over unsafe code.

You'll see this practice in other languages too; if you're coding safe Java, you're using a lot of unsafe code from the JVM and via JNI.

If you're using Python, the stdlib and all the performance-sensitive libraries (numpy, pandas, etc) are written in unsafe code, but even when you import those we still say your Python code is safe, and that Python overall is a memory safe language.