Both Java and Go also have unsafe, and are often used for FFI/Performance, and some popular/foundational libraries (like Google's Protobuf library in Java) use unsafe just for added performance. Heck, Go has an Assembler. So that's off the table as far as safety comparisons go. "But they don't use it as much" is also not an argument. #[forbid(unsafe_code)] and rely on the RustBelt formally verified standard library, problem solved.
Memory leaks are not a memory safety error, especially when deliberate (think calling malloc without ever calling free is perfectly safe, especially if you intend it as a static duration allocation). Unintentional memory leaks like Rc/Arc cycles are not a problem that occurs in garbage collected language, true, but also not a memory safety issue, unless it's unsafe code that relies on drop() being called or something.
So if we count data races, which you mentioned, Rust is in fact safer than Java/Go.
“But they don’t use it as much” is not an argument?
It’s the whole case for Rust > modern C++ based on that?
Rust can have memory issues, but “it doesn’t use unsafe as much” as modern C++. Forbidding unsafe code doesn’t guarantee vulnerabilities are gone.
why is it that when talking about C++ memory safety, even a bit more is worth everything, but when talking about rust vs python, suddenly it doesn’t matter if it’s less.
No one is writing kernels, raw register level volatile DMA bit-banging embedded code, and other "impossible without unsafe" code in Java/Go (Ok, almost no one, don't @ me, pjmlp, there are kernels built in memory-safe languages and there's tinygo for embedded etc. But they obviously use unsafe all the same). So they don't need to use it as much (standard library, core primitives and runtime implementation notwithstanding, and boy oh boy is it unsafe!)
Shifting the discussion to Vulns., Modern C++ is moving the goalposts a bit, don't you feel?
> Forbidding unsafe code doesn’t guarantee vulnerabilities are gone
It does, because if it doesn't, or GC'd languages offer more protection, then it's a bug in rustc/spec/core libs, for all intents and purposes.
Might as well mention /proc/self/mem and other filesystem/IO related exploits, because Rust can't protect you from them, and therefore it's completely and utterly unsafe and unfit for use.
I am not saying rust is unfit and I think your first sentence gets to sorta my point.
I agree no one writes actual kernels in GC languages. 100% Rust is the best choice where GCs can’t be.
I think my argument is that if you can use a GC, I think it’s considered best practice to use a GC. If you need thread safety, use a GC language like Elixir that handles concurrency well.
Like there’s no reason to act like Java community and try to force rust into every area. It’s very good at what it does, let it stay there.
I don't even disagree with these points! But if you go down to language lawyering and semantics, I think one could technically make a case for Rust being safer (in the memory safety sense) than Java/Go/(insert any GC'd memory safe language that features synchronization primitives as an opt-in feature, think volatile in Java), if only on the merit of protecting you from data races.
Elixir is great, use elixir. I certainly am not stopping you, it's completely safe and fault tolerant. Or maybe I'm saying this because I don't know as much about Elixir/BEAM internals compared to the aforementioned languages, who knows.
That’s not true - if anything, Java is much more memory safe. Even data races are well-defined and are not prone to “out-of-thin-air” values.
If you ever go down the safe road in Rust (be it a buggy library n layers down that you use from entirely safe code), you can no longer be sure in anything, a data race is entirely undefined behavior.
How is it different from "If you ever go down the JNI road in Java"? Be it a library the bundles RocksDB, or Android stuff, doesn't matter that your average Spring Boot developer probably won't be having any native dependencies (unless they use Kafka Streams or something else that bundles a native dependency that had CVEs that needed to be patched). Just as a Rust high-level Back-End developer that works with axum, sqlx, tokio etc. (vs Netty/NIO in Java for example, which also use unsafe/native code) hopefully won't be using buggy unsafe libraries.
Does the JVM protect you from partial reads? On Hotspot or on say, GraalVM's LLVM runtime too? Does Go? I assume they at least protect you from stale read UAFs by virtue still being traceable. (This is a genuine question).
Java is probably the most self-reliant platform out there, it is almost completely pure, as in being written in Java or in another JVM language. Besides places where it is absolutely necessary (e.g. opengl), there is simply no JNI used, or only very rarely.
Memory leaks are not a memory safety error, especially when deliberate (think calling malloc without ever calling free is perfectly safe, especially if you intend it as a static duration allocation). Unintentional memory leaks like Rc/Arc cycles are not a problem that occurs in garbage collected language, true, but also not a memory safety issue, unless it's unsafe code that relies on drop() being called or something.
So if we count data races, which you mentioned, Rust is in fact safer than Java/Go.