|
|
|
|
|
|
by maybebug
12 days ago
|
|
|
> 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. |
|
|
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.