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.
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 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.
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.
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.
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).