6 ms·

Do you need memory safety? Then why use Rust when you could use Java, JS, Python, etc? You can't "disable" memory safety in those languages. Do you need bare m

by bogwog 3y ago

Do you need memory safety? Then why use Rust when you could use Java, JS, Python, etc? You can't "disable" memory safety in those languages. Do you need bare metal performance? Then why use Rust when you could use C or C++, which have much larger ecosystems, platform support, more mature tooling, etc. Do you need BOTH memory safety and baremetal performance at the same time? Then there really aren't many other options besides Rust. But what I've started wondering lately is: are there really that many situations where you actually need both of those things at the same time? C++ tends to get misused a lot, but I feel like the same thing is happening with Rust.

Kenji 3y ago
[dead]
jackpeterfletch 3y ago
> Do you need memory safety? I think that’s an unusual way frame that requirement. All programs need to handle memory _correctly_. Very few seg fault as part of expected operation.
- bogwog 3y ago
  > Do you need memory safety guarantees? Is that better?
- jrpelkonen 3y ago
  Segfaults are not actually even the worst outcome, corrupting the program state yet still trucking along can lead to far worse consequences.
AlotOfReading 3y ago
If you're remotely sane, you'll always want memory safety. That's not really an optional property, because even in C/C++ compromising memory safety throws you straight into the land of nasal demons. The question is whether you want the compiler to ensure memory safety, or to do it completely on your own without language support. Personally, I've never met anyone who can ensure memory safety in their C/C++ without onerous restrictions even more severe than those rust imposes, but maybe you're superhuman.
- galangalalgol 3y ago
  And saying c++ has more mature tooling seems insane too. Anyone who has had to mess with depedency trees using git submodules and cmake, conan, bazel, vcpkg, and meson would not call the tooling, oh and hunter too!, mature.
  - yagni_dev 3y ago
    You have no idea what tooling means in this context!
    - galangalalgol 3y ago
      I'm willing to admit that is likely, could you enlighten me? I've done professional c++ for a couple decades. My pipelines usually were conan with some dependencies that were not. The used clang tidy and format, san, cppcheck, coverity and tested release and debug builds with clang and gcc. Coverage was sometimes just clang. But sometimes gcc as well. Tests were usually google test. The team standard IDE was vscode. Rust has rustfmt which is one standard. It has clippy which in addition to actual defects it forces commin idioms so code looks familiar. It has san and llvm coverage. It has miri. It supports aflop for fuzzing. And it has a single tool for package management and build. Edit: IDE is still vscode and it works great. The only tooling missing for rust would be formal analysis, which is in work (and which isn't that great a story on c++ either) and gcc. A gcc front end is in work, and there is mrustc to generate c from rust, but yes, gcc front end support would be nice to get all those extra targets without the extra work.
sunshowers 3y ago
A full 70% of security vulnerabilities are caused by memory safety issues. As professionals we need to get serious and have memory safety as a baseline requirement.
- bogwog 3y ago
  So we shouldn't use Rust at all, since Rust is not completely memory safe since it let's you disable the borrow checker. We should be serious as professionals and use safe languages like Java, JS, Python, etc. But of course there are use cases where you need memory safety guarantees and bare metal performance. In those cases, sacrificing some memory safety by using Rust is an acceptable tradeoff I think.
  - sunshowers 3y ago
    Ah, I forgot I was on Hacker News. All memory-safe languages are built on an unsafe foundation. The Java HotSpot VM is very unsafe C++. That's just how computers work. You aren't meaningfully sacrificing memory safety by using Rust because the unsafe sections are clearly marked out. That's similar to unsafe C#, Python with ctypes, and many other memory-safe languages.
  - tialaramex 3y ago
    > Rust is not completely memory safe since it let's you disable the borrow checker. No, it doesn't. What's interesting isn't so much that random HN posters believe this sort of thing, because hey, who needs to know anything about a topic to post their opinion on a forum right? No, what's fascinating is that this applies to people like Herb Sutter in his "cpp2" language, here's Herb: > I don’t like monolithic "unsafe" that turns off checking for all rules Nobody does that. It's possible Herb knows that and is being deceitful but honestly I think it's more likely that without investigating at all Herb has just decided everybody else is an idiot...
    - defen 3y ago
      fn trust_me_i_dont_need_a_borrow_checker<'a, 'b> (x: &'a mut u32) -> &'b mut u32 { unsafe { core::mem::transmute(x) } } fn main() { let mut owned = vec![40, 2]; let mut_1 = trust_me_i_dont_need_a_borrow_checker(&mut owned[0]); let mut_2 = trust_me_i_dont_need_a_borrow_checker(&mut owned[1]); drop(owned); let undefined = *mut_1 + *mut_2; println!("The answer is {undefined}"); }
cmrdporcupine 3y ago
Beyond memory safety, Rust's other advantages over C++ are simply that it has a far better type system (by nature of ADTs), cleaner and more consistent syntax, cleaner tooling overall, and a far better module/modularity story. That, and the borrowing/safety aspects of Rust also shake out into threading/concurrency, where the compiler does a pretty good job of forcing you to adopt better practices in regards to state sharing, locking, concurrency. Cargo, though... I am coming around to thinking isn't great -- workspace support remains half-assed, especially... and crates.io is amateur-hour for reasons many people have pointed out elsewhere on this post. I have been tempted to switch my personal projects to bazel, with 3rd-party deps checked in/submoduled.
paholg 3y ago
In addition to memory safety and performance, Rust offers something that, as far as I'm aware, no other mainstream languages offer: protection from data races. And it offers those things along with a fantastic type system, and great tooling.

by bogwog 3y ago

Kenji 3y ago

[dead]

jackpeterfletch 3y ago

> Do you need memory safety? I think that’s an unusual way frame that requirement. All programs need to handle memory _correctly_. Very few seg fault as part of expected operation.

bogwog 3y ago
> Do you need memory safety guarantees? Is that better?
jrpelkonen 3y ago
Segfaults are not actually even the worst outcome, corrupting the program state yet still trucking along can lead to far worse consequences.

AlotOfReading 3y ago

If you're remotely sane, you'll always want memory safety. That's not really an optional property, because even in C/C++ compromising memory safety throws you straight into the land of nasal demons. The question is whether you want the compiler to ensure memory safety, or to do it completely on your own without language support. Personally, I've never met anyone who can ensure memory safety in their C/C++ without onerous restrictions even more severe than those rust imposes, but maybe you're superhuman.

galangalalgol 3y ago
And saying c++ has more mature tooling seems insane too. Anyone who has had to mess with depedency trees using git submodules and cmake, conan, bazel, vcpkg, and meson would not call the tooling, oh and hunter too!, mature.
- yagni_dev 3y ago
  You have no idea what tooling means in this context!
  - galangalalgol 3y ago
    I'm willing to admit that is likely, could you enlighten me? I've done professional c++ for a couple decades. My pipelines usually were conan with some dependencies that were not. The used clang tidy and format, san, cppcheck, coverity and tested release and debug builds with clang and gcc. Coverage was sometimes just clang. But sometimes gcc as well. Tests were usually google test. The team standard IDE was vscode. Rust has rustfmt which is one standard. It has clippy which in addition to actual defects it forces commin idioms so code looks familiar. It has san and llvm coverage. It has miri. It supports aflop for fuzzing. And it has a single tool for package management and build. Edit: IDE is still vscode and it works great. The only tooling missing for rust would be formal analysis, which is in work (and which isn't that great a story on c++ either) and gcc. A gcc front end is in work, and there is mrustc to generate c from rust, but yes, gcc front end support would be nice to get all those extra targets without the extra work.

sunshowers 3y ago

A full 70% of security vulnerabilities are caused by memory safety issues. As professionals we need to get serious and have memory safety as a baseline requirement.

bogwog 3y ago
So we shouldn't use Rust at all, since Rust is not completely memory safe since it let's you disable the borrow checker. We should be serious as professionals and use safe languages like Java, JS, Python, etc. But of course there are use cases where you need memory safety guarantees and bare metal performance. In those cases, sacrificing some memory safety by using Rust is an acceptable tradeoff I think.
- sunshowers 3y ago
  Ah, I forgot I was on Hacker News. All memory-safe languages are built on an unsafe foundation. The Java HotSpot VM is very unsafe C++. That's just how computers work. You aren't meaningfully sacrificing memory safety by using Rust because the unsafe sections are clearly marked out. That's similar to unsafe C#, Python with ctypes, and many other memory-safe languages.
- tialaramex 3y ago
  > Rust is not completely memory safe since it let's you disable the borrow checker. No, it doesn't. What's interesting isn't so much that random HN posters believe this sort of thing, because hey, who needs to know anything about a topic to post their opinion on a forum right? No, what's fascinating is that this applies to people like Herb Sutter in his "cpp2" language, here's Herb: > I don’t like monolithic "unsafe" that turns off checking for all rules Nobody does that. It's possible Herb knows that and is being deceitful but honestly I think it's more likely that without investigating at all Herb has just decided everybody else is an idiot...
  - defen 3y ago
    fn trust_me_i_dont_need_a_borrow_checker<'a, 'b> (x: &'a mut u32) -> &'b mut u32 { unsafe { core::mem::transmute(x) } } fn main() { let mut owned = vec![40, 2]; let mut_1 = trust_me_i_dont_need_a_borrow_checker(&mut owned[0]); let mut_2 = trust_me_i_dont_need_a_borrow_checker(&mut owned[1]); drop(owned); let undefined = *mut_1 + *mut_2; println!("The answer is {undefined}"); }

cmrdporcupine 3y ago

Beyond memory safety, Rust's other advantages over C++ are simply that it has a far better type system (by nature of ADTs), cleaner and more consistent syntax, cleaner tooling overall, and a far better module/modularity story. That, and the borrowing/safety aspects of Rust also shake out into threading/concurrency, where the compiler does a pretty good job of forcing you to adopt better practices in regards to state sharing, locking, concurrency. Cargo, though... I am coming around to thinking isn't great -- workspace support remains half-assed, especially... and crates.io is amateur-hour for reasons many people have pointed out elsewhere on this post. I have been tempted to switch my personal projects to bazel, with 3rd-party deps checked in/submoduled.

paholg 3y ago

In addition to memory safety and performance, Rust offers something that, as far as I'm aware, no other mainstream languages offer: protection from data races. And it offers those things along with a fantastic type system, and great tooling.