5 ms·

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. Rust is

by 3a2d29 4y ago

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

LecroJS 4y ago
I have only dabbled in Rust and have no experience with C++/Java/Go. Can you help me understand how those languages would be more memory safe than Rust? My understanding was that safe code was a solution to memory leaks. What’s the benefit to safe rust code if it isn’t getting rid of memory leaks?
- 3a2d29 4y ago
  Memory leaks are not memory safety. Memory leaks in all languages are safe, they just slow performance and cause crashes. Rust still memory leaks.
  - LecroJS 4y ago
    Thanks. So what does it mean for a program to be memory safe if it can still memory leak? An example or pointing to a resource for further reading would be much appreciated.
    - Vecr 4y ago
      It prevents data races, use-after-free, double-free, buffer overflow, invalid type punning, etc. You can still do all those things in unsafe code though, and you could in safe code if the unsafe code you depend on (including the kernel) behave/are programmed incorrectly. You can also have hardware issues and stochastic bit flips that Rust and SPARK can't deal with.
    - Jtsummers 4y ago
      > So what does it mean for a program to be memory safe if it can still memory leak? That it's not actually memory safe. Memory leaks are part of memory unsafety.
      - Hemospectrum 4y ago
        That’s not correct. Memory safety consists of properties necessary for type safety to be upheld. Leaks alone can crash a program but can’t defeat type safety.
- latifk 4y ago
  Because memory leaks are memory safe in rust, they just cause a performance hit.
- giaour 4y ago
  Memory safe code does not prevent applications from using too much memory; it prevents applications from accessing the wrong memory (e.g., by using a variable after its underlying value has been freed and the memory reallocated).
mirashii 4y ago
I'd put Rust as more memory safe than golang as golang's memory safety guarantees fall apart under data races, which are not prevented in the language. Rust will still require you type unsafe. You can cause memory safety in golang without using any unsafe facilities. > 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.
- 3a2d29 4y ago
  I’m not at all saying I do know a lot on the topic, I am saying I know enough to recognize comments that are wrong. 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.
- gunapologist99 4y ago
  Golang does have an excellent built-in data race detector, which shows exactly which threads (and functions) are colliding. https://go.dev/doc/articles/race_detector 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): https://go.dev/blog/waza-talk https://go.dev/blog/waza-talk
zRedShift 4y ago
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.
- 3a2d29 4y ago
  “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.
  - zRedShift 4y ago
    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.
ksml 4y ago
Go and Java can memory leak too. Furthermore, they are susceptible to data races that are not possible in safe Rust.
- 3a2d29 4y ago
  It’s a lot harder to memory leak in Go and Java than rust. 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.
  - super_flanker 4y ago
    > If you are a rust dev that forces your language into areas where a GC would suffice 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.
deleted 4y ago
[deleted]

by 3a2d29 4y ago

LecroJS 4y ago

I have only dabbled in Rust and have no experience with C++/Java/Go. Can you help me understand how those languages would be more memory safe than Rust? My understanding was that safe code was a solution to memory leaks. What’s the benefit to safe rust code if it isn’t getting rid of memory leaks?

3a2d29 4y ago
Memory leaks are not memory safety. Memory leaks in all languages are safe, they just slow performance and cause crashes. Rust still memory leaks.
- LecroJS 4y ago
  Thanks. So what does it mean for a program to be memory safe if it can still memory leak? An example or pointing to a resource for further reading would be much appreciated.
  - Vecr 4y ago
    It prevents data races, use-after-free, double-free, buffer overflow, invalid type punning, etc. You can still do all those things in unsafe code though, and you could in safe code if the unsafe code you depend on (including the kernel) behave/are programmed incorrectly. You can also have hardware issues and stochastic bit flips that Rust and SPARK can't deal with.
  - Jtsummers 4y ago
    > So what does it mean for a program to be memory safe if it can still memory leak? That it's not actually memory safe. Memory leaks are part of memory unsafety.
    - Hemospectrum 4y ago
      That’s not correct. Memory safety consists of properties necessary for type safety to be upheld. Leaks alone can crash a program but can’t defeat type safety.
latifk 4y ago
Because memory leaks are memory safe in rust, they just cause a performance hit.
giaour 4y ago
Memory safe code does not prevent applications from using too much memory; it prevents applications from accessing the wrong memory (e.g., by using a variable after its underlying value has been freed and the memory reallocated).

mirashii 4y ago

I'd put Rust as more memory safe than golang as golang's memory safety guarantees fall apart under data races, which are not prevented in the language. Rust will still require you type unsafe. You can cause memory safety in golang without using any unsafe facilities. > 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.

3a2d29 4y ago
I’m not at all saying I do know a lot on the topic, I am saying I know enough to recognize comments that are wrong. 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.
gunapologist99 4y ago
Golang does have an excellent built-in data race detector, which shows exactly which threads (and functions) are colliding. https://go.dev/doc/articles/race_detector 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): https://go.dev/blog/waza-talk https://go.dev/blog/waza-talk

zRedShift 4y ago

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.

3a2d29 4y ago
“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.
- zRedShift 4y ago
  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.

ksml 4y ago

Go and Java can memory leak too. Furthermore, they are susceptible to data races that are not possible in safe Rust.

3a2d29 4y ago
It’s a lot harder to memory leak in Go and Java than rust. 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.
- super_flanker 4y ago
  > If you are a rust dev that forces your language into areas where a GC would suffice 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.

deleted 4y ago

[deleted]