6 ms·

Dumb question, it always seems like people say Rust is the gold standard for memory safety. Why is Rust better at memory safety than C#, Go, Java, Ruby or Swif

Dumb question, it always seems like people say Rust is the gold standard for memory safety. Why is Rust better at memory safety than C#, Go, Java, Ruby or Swift?

msgilligan 4y ago
My understanding is that Rust provides memory safety with less overhead than languages that provide memory-safety via garbage collection. This comes at the price of some extra cognitive load for developers, but is appropriate for many applications where the added performance is needed. (Not necessarily "better" overall, but a better choice for certain applications.)
ok123456 4y ago
It's not. Garbage collection is fine. Rust just imposes constraints on references using the type system, so the compiler knows to emit the free in the right spot. For regular application code there's no real benefit. It's not really a systems language because of all the hidden memory allocations and lack of a stable ABI. It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget.
- zRedShift 4y ago
  > For regular application code there's no real benefit Can't disagree, naive garbage collected code would outperform naive Rust code that allocates Strings and Vecs up the wazoo. And performance isn't a real issue with simple CRUD/ORM-type services. Wrapping business logic in newtypes and enforcing specific invariants for them and serde style "parse don't validate", can do wonders for business logic, but then again you can probably just use a garbage collected functional language with dependent typing and a bunch of other tricks in its hat, and get more mileage out of it, if that's the code you write. > It's not really a systems language because of all the hidden memory allocations C and C++(especially) can hide memory allocation just fine themselves. Allocations are pretty explicit in Rust, but layers of libraries can hide those (if you don't use no_std and the like), just like in C or C++. > lack of a stable ABI there is the C ABI, a stable Rust ABI at any stage would just be an optimization killer and a massive PITA, ask C++. Stable ABI, international standard, and multiple implementations of the compiler, are not a requirement for a systems language. For a language that relies on compile-time monomorphization, a stable ABI beyond what C already provides gives precious little. Swift ABI forgoes monomorphization, but it's not really a trade-off a systems language should embrace. The template header issue in C++, I won't even touch. There are also crates in the ecosystem that can generate 2-way FFI glue code to provide a stable ABI for Rust based on extern "C". > It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget. We use embedded Rust on a memory constrained MCU and besides slightly increasing the maximum stack size (because less is allocated on the heap), memory budget is not an issue we have. And in LLVM 16, Rust's stack usage will decrease even more, due to recent optimizations. You don't need to use "gratuitous copies", you can statically allocate just fine, and if your value is ephemeral and is read/mutated by multiple threads, heap allocating with reference counting is just fine.
acdha 4y ago
It depends on exactly what features you class in the safety umbrella. Both languages protect against classic C mistakes but Rust has a far more advanced type system and better safety culture. For example, Java has had issues with data races which would have been caught by Rust and things like null safety have historically been an issue. Both are better than C but I’d expect a good programmer to be more productive in Rust and to avoid more logic errors (which may or may not be security issues), not to mention the many problems caused by widely used open-source libraries written during the bad old days which have extensive dependencies and often enable risky behaviors by default. Culture isn’t a core language feature but it matters.
- svick 4y ago
  A NullPointerException is not a security vulnerability. A race condition might, but even then, I'm not sure how likely that is to result in a vulnerability in a garbage collected language.
  - acdha 4y ago
    NPE itself isn’t likely to be exploitable, no, but what I had in mind was more along the lines of code with logic errors handling rare cases where something is null. There’s a lot of tooling designed to catch things like that but the worst code bases tend not to use them because they’d need a lot of cleanup.
- 3a2d29 4y ago
  but with a GC, Java/Go/etc are inherently more safe than rust. Rust can have double-frees and some of the most serious memory safety errors that those cannot.
  - acdha 4y ago
    Rust’s scoping rules prevent most double free errors. You can get them with certain techniques but it’s also possible, say, use JNI to shoot yourself in the foot, too. Basically, I’d say that at fond point this gets to be a lot more complicated because you’re talking about which sets of features & cultural practices make you more or less likely to make exploitable errors. Does using a GC buy you enough to balance out the complexity fetish common in the open source Java world? Which is safer probably depends on what type of projects you work on.
deleted 4y ago
[deleted]

Dumb question, it always seems like people say Rust is the gold standard for memory safety. Why is Rust better at memory safety than C#, Go, Java, Ruby or Swift?

msgilligan 4y ago

My understanding is that Rust provides memory safety with less overhead than languages that provide memory-safety via garbage collection. This comes at the price of some extra cognitive load for developers, but is appropriate for many applications where the added performance is needed. (Not necessarily "better" overall, but a better choice for certain applications.)

ok123456 4y ago

It's not. Garbage collection is fine. Rust just imposes constraints on references using the type system, so the compiler knows to emit the free in the right spot. For regular application code there's no real benefit. It's not really a systems language because of all the hidden memory allocations and lack of a stable ABI. It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget.

zRedShift 4y ago
> For regular application code there's no real benefit Can't disagree, naive garbage collected code would outperform naive Rust code that allocates Strings and Vecs up the wazoo. And performance isn't a real issue with simple CRUD/ORM-type services. Wrapping business logic in newtypes and enforcing specific invariants for them and serde style "parse don't validate", can do wonders for business logic, but then again you can probably just use a garbage collected functional language with dependent typing and a bunch of other tricks in its hat, and get more mileage out of it, if that's the code you write. > It's not really a systems language because of all the hidden memory allocations C and C++(especially) can hide memory allocation just fine themselves. Allocations are pretty explicit in Rust, but layers of libraries can hide those (if you don't use no_std and the like), just like in C or C++. > lack of a stable ABI there is the C ABI, a stable Rust ABI at any stage would just be an optimization killer and a massive PITA, ask C++. Stable ABI, international standard, and multiple implementations of the compiler, are not a requirement for a systems language. For a language that relies on compile-time monomorphization, a stable ABI beyond what C already provides gives precious little. Swift ABI forgoes monomorphization, but it's not really a trade-off a systems language should embrace. The template header issue in C++, I won't even touch. There are also crates in the ecosystem that can generate 2-way FFI glue code to provide a stable ABI for Rust based on extern "C". > It's garbage for embedded because of all the gratuitous copies you have to make to appease the borrow checker. It blows up your memory budget. We use embedded Rust on a memory constrained MCU and besides slightly increasing the maximum stack size (because less is allocated on the heap), memory budget is not an issue we have. And in LLVM 16, Rust's stack usage will decrease even more, due to recent optimizations. You don't need to use "gratuitous copies", you can statically allocate just fine, and if your value is ephemeral and is read/mutated by multiple threads, heap allocating with reference counting is just fine.

acdha 4y ago

It depends on exactly what features you class in the safety umbrella. Both languages protect against classic C mistakes but Rust has a far more advanced type system and better safety culture. For example, Java has had issues with data races which would have been caught by Rust and things like null safety have historically been an issue. Both are better than C but I’d expect a good programmer to be more productive in Rust and to avoid more logic errors (which may or may not be security issues), not to mention the many problems caused by widely used open-source libraries written during the bad old days which have extensive dependencies and often enable risky behaviors by default. Culture isn’t a core language feature but it matters.

svick 4y ago
A NullPointerException is not a security vulnerability. A race condition might, but even then, I'm not sure how likely that is to result in a vulnerability in a garbage collected language.
- acdha 4y ago
  NPE itself isn’t likely to be exploitable, no, but what I had in mind was more along the lines of code with logic errors handling rare cases where something is null. There’s a lot of tooling designed to catch things like that but the worst code bases tend not to use them because they’d need a lot of cleanup.
3a2d29 4y ago
but with a GC, Java/Go/etc are inherently more safe than rust. Rust can have double-frees and some of the most serious memory safety errors that those cannot.
- acdha 4y ago
  Rust’s scoping rules prevent most double free errors. You can get them with certain techniques but it’s also possible, say, use JNI to shoot yourself in the foot, too. Basically, I’d say that at fond point this gets to be a lot more complicated because you’re talking about which sets of features & cultural practices make you more or less likely to make exploitable errors. Does using a GC buy you enough to balance out the complexity fetish common in the open source Java world? Which is safer probably depends on what type of projects you work on.

deleted 4y ago

[deleted]