Rust is safer than C++ because it does “opt-out” of memory safety, rather than modern C++ which is more “opt-in”
But Rust (other than for threads) is definitely not more memory safe than Go/Java etc. Safe rust code can still memory leak. Unsafe rust code can have memory errors (and does frequently) that those others would stop.
> Safe rust code can still memory leak.
Which is not at all a violation of memory safety, so is moot here.
> Unsafe rust code can have memory errors (and does frequently) that those others would stop.
Unsafe C#, unsafe Java, safe Go, Python all suffer from the same types of memory errors.
> What’s kinda annoying about comment sections on these articles is it shows how many people have opinions on this topic that they know only a bit about.
I'd invite you to pause and ask yourself if you know as much about the topic as you think you might, as there are either clear misunderstandings or intentional misleadings about these languages in your very short post.
For starters just cause you “can” have memory safety issues doesn’t mean it’s the same as Rust.
I mean Rust “can” have memory safety issues, so I guess it’s equal to C++? No that’s ridiculous.
So just cause you “can” have unsafety in python doesn’t mean suddenly it’s not better than rust.
If you think memory issues mean rust is better than C++, then you must recognize all GC languages are better than rust. Rust should be used where GCs cannot.
Memory leaks are still a very real issue. Just cause they aren’t a security issue doesn’t mean they don’t affect reliability, which is important.
https://go.dev/doc/articles/race_detector
Caveats are that it requires cgo, and it might have lower performance, so enable it during development but not during production. Also detection requires actually triggering the data race, so you need good tests to try to exercise those areas of code.
Although Rust prevents them outright, that does seem to come at the expense at some flexibility, and the actual security risk of a data race in Golang seems to be moot. For example, if you know that a shared object will only be used when the program is starting up and in single-threaded mode, then you can safely use it then without a mutex.
Even when Golang does have a data race, the race causes the program (or at least the thread) to panic and thus is probably not directly exploitable, unlike older languages.
In other words, golang changes the risk of a data race from being a vulnerability to just a program-crashing bug. [EDIT: please see comments below which indicates that this may not be true in all cases, especially if you're trying to sandbox untrusted code!]
Beyond that, Go provides special capabilities (channels) to allow communications across goroutines (which are analogous to threads but can also automatically use different cores, unlike regular threads). Channels are like a vastly improved version of Erlang's mailboxes, and are the best way to pass information between goroutines.
So, rather than use mutexes, channels are Golang's idiomatic way to eliminate data races entirely. You can pass any complex object through a channel to another listener (blocking or non-blocking) on the other side. This excellent video is actually what convinced me to switch to Go for concurrent coding (which is the only place where you run into data races anyway):
I don't believe this is true, people have demonstrated using data races to build arbitrary code execution primitives. See for example https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
Looking at the attack vector (https://blog.stalkr.net/2019/11/the-gomium-browser-google-ct...), this is a pretty tightly constrained circumstance where you are permitting an attacker to execute unknown Golang code within the context of your process. (perhaps like the Go Playground, if that's not starting a new process for each user.)
I don't personally think that's really that applicable to regular golang users, unless they're trying to sandbox Golang code somehow within the language itself. (And if you are allowing untrusted code, then it's basically game over anyway).
But it's still interesting and I added a note to my comment above about your point.
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.
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).
Just like it’s harder to have a memory safety issue in rust than C++.
if you are worried about data races, use a language like elixir that’s more safe than rust and is great for concurrency.
If you are a rust dev that forces your language into areas where a GC would suffice, than you are just like C++ devs who refuse to use rust for memory safety.
You are introducing memory issues just cause you don’t want to use a better tool.
What's wrong in using Rust where a GC would suffice? Rust type system gives it a more high level feeling than go could ever provide.
Memory leaks in all languages are safe, they just slow performance and cause crashes.
Rust still memory leaks.
That it's not actually memory safe. Memory leaks are part of memory unsafety.