Comment by Ar-Curunir
1 day ago
What? Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe. Unsafe rust is not memory-safe, but you generally don't need to have a lot of it around.
1 day ago
What? Zig is definitively not memory-safe, while safe Rust, is, by definition, memory-safe. Unsafe rust is not memory-safe, but you generally don't need to have a lot of it around.
By definition yes. There were a lot of lies to persuade managers. You can write a lot into your documentation.
But by implementation and spec definitely not.
The second you have any `unsafe`, Rust is _by definition_ not memory-safe.
By that definition, Python is not memory-safe, Java is not memory-safe, Go is not memory-safe, and so on. All of these languages contain escape hatches to do memory-unsafe stuff, yet no one is calling them memory unsafe.
Go is more memory unsafe than Java or Rust. Data races in concurrent Go code can cause memory corruption, unlike in concurrent Java code. Safe Rust is designed to avoid data races altogether using static analysis.
And the majority of the Rust standard library uses `unsafe`.
Prove it. Show me the stats that the standard library is over 50% unsafe.
1 reply →
Safe Rust is demonstrably not memory-safe: https://github.com/Speykious/cve-rs/tree/main
This is a compiler bug. This has no bearing on the language itself. Bugs happen, and they will be fixed, even this one.
It's a 10 year old bug which will eventually be fixed but may require changes to how Rust handles type variance.
Until you guys write an actual formal specification, the compiler is the language.
10 replies →