5 ms·

No, the Rust community almost universally understands "safe" as referring to memory safety, as per Rust's documentation, and especially the unsafe book, aka Rus

No, the Rust community almost universally understands "safe" as referring to memory safety, as per Rust's documentation, and especially the unsafe book, aka Rustonomicon [1]. In that regard, Safe Rust is safe, Unsafe Rust is unsafe, and C++ is also unsafe. I don't think anyone is saying "C++ is all unsafe." You might be talking about "correct", and that's true, Rust generally favors correctness more than most other languages (e.g. Rust being obstinate about turning a byte array into a file path, because not all file paths are made of byte arrays, or e.g. the myriad string types to denote their semantics). [1] https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

pjmlp 2y ago
Mostly, there is a sub culture that promotes to taint everything as unsafe that could be used incorrectly, instead of memory safety related operations.
- dymk 2y ago
  That subculture is called “people who haven’t read the docs”, and I don’t see why anyone would give a whole lot of weight to their opinion on what technical terms mean
  - arccy 2y ago
    I don't see why people would drop the "memory" part of "memory safe" and just promote the false advertising of "safe rust"
    - an_ko 2y ago
      It sounds like you should read the docs. It's just a subject-specific abbreviation, not an advertising trick.
      - arccy 2y ago
        but it is false advertising when it's used all over the internet with: rust is safe! telling the whole world to rtfm for your co-opting of the generic word "safe" is like advertisers telling you to read the fine print: a sleazy tactic.
        goku12 2y ago
        It's not that either, and you are validating the GP's point. Rust has a very specific 'unsafe' keyword that every Rust developer interpret implicitly and instinctively as 'potentially memory-unsafe'. Consequently, 'safe' is interpreted as the opposite - 'guaranteed memory-safe'. Using that word as an abbreviation among Rust developers is therefore not uncommon. However while speaking about Rust language in general, all half-decent Rust developers specify that it's about memory safety. Even the Rust language homepage has only two instances of the word - 'memory-safety' and 'thread-safety'. The accusations of sleaziness and false accusations is disingenuous at best.
  - pkhuong 2y ago
    Someone tell that to the standard library. No memory safety involved in non-zero numbers https://doc.rust-lang.org/std/num/struct.NonZero.html#tymethod.new_unchecked https://doc.rust-lang.org/std/num/struct.NonZero.html#tymeth...
    - whytevuhuni 2y ago
      There is, since the zero is used as a niche value optimisation for enums, so that Option<NonZero<u32>> occupies the same amount of memory as u32. But this can be used with other enums too, and in those cases, having a zero NonZero would essentially transmute the enum into an unexpected variant, which may cause an invariant to break, thus potentially causing memory unsafety in whatever required that invariant.
      - zozbot234 2y ago
        > which may cause an invariant to break, thus potentially causing memory unsafety in whatever required that invariant By that standard anything and everything might be tainted as "unsafe", which is precisely GP's point. Whether the unsafety should be blamed on the outside code that's allowed to create a 0-valued NonZero<…> or on the code that requires this purported invariant in the first place is ultimately a matter of judgment, that people may freely disagree about.
        genrilz 2y ago
        EDIT: A summary of this is that it is impossible to write a sound std::Vec implementation if NonZero::new_unchecked is a safe function. This is specifically because creating a value of NonZero which is 0 is undefined behavior which is exploited by niche optimization. If you created your own `struct MyNonZero(u8)`, then you wouldn't need to mark MyNonZero::new_unchecked as unsafe because creating MyNonZero(0) is a "valid" value which doesn't trigger undefined behavior. The issue is that this could potentially allow creating a struct whose invariants are broken in safe rust. This breaks encapsulation, which means modules which use unsafe code (like `std::vec`) have no way to stop safe code from calling them with the invariants they rely on for safety broken. Let me give an example starting with an enum definition: // Assume std::vec has this definition struct Vec<T> { capacity: usize, length: usize, arena: * T } enum Example { First { capacity: usize, length: usize, arena: usize, discriminator: NonZero<u8> }, Second { vec: Vec<u8> } } Now assume the compiler has used niche optimization so that if the byte corresponding to `discriminator` is 0, then the enum is `Example::Second`, while if the byte corresponding to `discriminator` is not 0, then the enum is `Example::First` with discriminator being equal to its given non-zero value. Furthermore, assume that `Example::First`'s `capacity`, `length`, and `arena` fields are in the in the same position as the fields of the same name for `Example::Second.vec`. If we allow `fn NonZero::new_unchecked(u8) -> NonZero<u8>` to be a safe function, we can create an invalid Vec: fn main() { let evil = NonZero::new_unchecked(0); // We write as an Example::First, // but this is read as an Example::Second // because discriminator == 0 and niche optimization let first = Example::First { capacity: 9001, length: 9001, arena: 0x20202020, discriminator: evil } if let Example::Second{ vec: bad_vec } = first { // If the layout of Example is as I described, // and no optimizations occur, we should end up in here. // This writes 255 to address 0x20202020 bad_vec[0] = 255; } } So if we allowed new_unchecked to be safe, then it would be impossible to write a sound definition of Vec.
  - Guthur 2y ago
    Because of cult like belief structures growing up around rust, it's clear as day for us on the outside, I see it from the evangelists in the company I work for "rust is faster and safer to develop with when compared to c++", I'm no c++ fan but it's obviously nonsense. I feel people took the comparison of rust to c and extrapolated to c++ which is blatantly disingenuous.
    - rcxdude 2y ago
      Care to explain the obvious, then? Rust is quite a lot nicer to write than C++ in my experience (and in fact, it seems like rust is most attractive to people who were already writing C++: people who still prefer C are a lot less likely to like Rust).
      - Guthur 2y ago
        There is nothing attractive about c++ or rust, I really don't understand how anyone can think so, it has to be some sort of Stockholm syndrome. Think about it, before you started programming what about your experiences would make you appreciate the syntax soup of rust and c++?
        rcxdude 2y ago
        I dunno, there's not much about my previous experience that would indicate much one way or the other. I have found, though, that I tend to prefer slightly denser, heterogeneous code and syntax than average. Low-syntax languages like Haskell and Lisps make my head hurt because the code is so formless it becomes hard for me to parse, while languages with more syntax and symbols are easier (though, there is a limit, APL,k, etc, are a little far I find)
    - goku12 2y ago
      The cult that I see growing online a lot are those who are invested in attacking Rust for some reason, though their arguments often indicate that they haven't even tried it. I believe that we're focusing so much on Rust evangelists that we're neglecting the other end of the zealotry spectrum - the irrational haters. The Rust developers I meet are more interested in showing off their creations than in evangelizing the language. Even those on dedicated Rust forums are generally very receptive to other languages - you can see that in action on topics like goreleaser or Zig's comptime. And while you have already dismissed the other commenter's experience of finding Rust nicer than C++ to program in, I would like to add that I share their experience. I have nothing against C++, and I would like to relearn it so that I can contribute to some projects I like. But the reason why I started with Rust in 2013 was because of the memory-saftey issues I was facing with C++. There are features in Rust that I find surprisingly pleasant, even with 6 additional years of experience in Python. Your opinion that Rust is unpleasant to the programmer is not universal and its detractions are not nonsense. I appreciate the difficulty in learning Rust - especially getting past the stage of fighting the borrow checker. That's the reason why I don't promote Rust for immediate projects. However, I feel that the knowledge required to get past that stage is essential even for correct C and C++. Rust was easy for me to get started in, because of my background in digital electronics, C and C++. But once you get past that peak, Rust is full of very elegant abstractions that are similar to what's seen in Python. I know it works because I have trained js and python developers in Rust. And their feedback corroborates those assumptions about learning Rust.
- Aurornis 2y ago
  I see this subculture far more in online forums than with fellow Rust developers. Most often, the comments come from people who don’t even write much Rust. They either know just enough to be dangerous or they write other languages and feel like it’s a “gotcha” they can use against Rust.
brundolf 2y ago
Formally the team/docs are very clear, but I think many users of Rust miss that nuance and lump memory safety together with all the other features that create the "if it compiles it probably works" experience So I agree with the above comment that the title could be better, but I also understand why the author gave it this title
- goku12 2y ago
  I agree with most of your assertions. > ... with all the other features that create the "if it compiles it probably works" experience While it's true that Rust's core safety feature is almost exclusively about memory safety, I think it contributes more to the overall safety of the program. My professional background is more in electronics than in software. So when the Rust borrow checker complains, I tend to map them to nuances of the hardware and seek work-arounds for those problems. Those work-arounds often tend to be better restructuring of the code, with proper data isolation. While that may seem like hard work in the beginning, it's often better towards the end because of clarity and modularity it contributes to the code. Rust won't eliminate logical bugs or runtime bugs from careless coding. But it does encourage better coding practices. In addition, the strict, but expressive type system eliminates more bugs by encoding some extra constraints that are verified at compile time. (Yes, there are other languages that do this better). And while it is not guaranteed, I find Rust programs to just work if it compiles, more often than in the other languages I know. And the memory-safety system has a huge role in that experience.
ampere22 2y ago
If a C++ developer decides to use purely containers and smart pointers when starting a new project, how are they going to develop unsafe code? Containers like std::vector and smart pointers like std::unique_ptr seem to offer all of the same statically checked guarantees that Rust does. I just do not see how Rust is a superior language compared to modern C++
- criddell 2y ago
  C++ devs need to understand the difference between: Vec1[0]; Vec1.at(0); Even the at method isn’t statically checked. If you want static checking, you probably need to use std::array.
  - pjmlp 2y ago
    Many also need to learn that there are configuration settings on their compilers that make those two cases the same, enabling bounds checking on operator[]().
    - criddell 2y ago
      Sure, but at() is guaranteed to throw an exception and operator[] can throw an exception when you go out of bounds. C++26 is tweaking this, but it's still going to differ implementation to implementation. At least that's my understanding of the situation. Happy to be corrected though.
- ddulaney 2y ago
  Unfortunately, operator[] on std::vector is inherently unsafe. You can potentially try to ban it (using at() instead), but that has its own problems. There’s a great talk by Louis Brandy called “Curiously Recurring C++ Bugs at Facebook” [0] that covers this really well, along with std::map’s operator[] and some more tricky bugs. An interesting question to ask if you try to watch that talk is: How does Rust design around those bugs, and what trade offs does it make? [0]: https://m.youtube.com/watch?v=lkgszkPnV8g https://m.youtube.com/watch?v=lkgszkPnV8g

pjmlp 2y ago

Mostly, there is a sub culture that promotes to taint everything as unsafe that could be used incorrectly, instead of memory safety related operations.

dymk 2y ago
That subculture is called “people who haven’t read the docs”, and I don’t see why anyone would give a whole lot of weight to their opinion on what technical terms mean
- arccy 2y ago
  I don't see why people would drop the "memory" part of "memory safe" and just promote the false advertising of "safe rust"
  - an_ko 2y ago
    It sounds like you should read the docs. It's just a subject-specific abbreviation, not an advertising trick.
    - arccy 2y ago
      but it is false advertising when it's used all over the internet with: rust is safe! telling the whole world to rtfm for your co-opting of the generic word "safe" is like advertisers telling you to read the fine print: a sleazy tactic.
      - goku12 2y ago
        It's not that either, and you are validating the GP's point. Rust has a very specific 'unsafe' keyword that every Rust developer interpret implicitly and instinctively as 'potentially memory-unsafe'. Consequently, 'safe' is interpreted as the opposite - 'guaranteed memory-safe'. Using that word as an abbreviation among Rust developers is therefore not uncommon. However while speaking about Rust language in general, all half-decent Rust developers specify that it's about memory safety. Even the Rust language homepage has only two instances of the word - 'memory-safety' and 'thread-safety'. The accusations of sleaziness and false accusations is disingenuous at best.
- pkhuong 2y ago
  Someone tell that to the standard library. No memory safety involved in non-zero numbers https://doc.rust-lang.org/std/num/struct.NonZero.html#tymethod.new_unchecked https://doc.rust-lang.org/std/num/struct.NonZero.html#tymeth...
  - whytevuhuni 2y ago
    There is, since the zero is used as a niche value optimisation for enums, so that Option<NonZero<u32>> occupies the same amount of memory as u32. But this can be used with other enums too, and in those cases, having a zero NonZero would essentially transmute the enum into an unexpected variant, which may cause an invariant to break, thus potentially causing memory unsafety in whatever required that invariant.
    - zozbot234 2y ago
      > which may cause an invariant to break, thus potentially causing memory unsafety in whatever required that invariant By that standard anything and everything might be tainted as "unsafe", which is precisely GP's point. Whether the unsafety should be blamed on the outside code that's allowed to create a 0-valued NonZero<…> or on the code that requires this purported invariant in the first place is ultimately a matter of judgment, that people may freely disagree about.
      - genrilz 2y ago
        EDIT: A summary of this is that it is impossible to write a sound std::Vec implementation if NonZero::new_unchecked is a safe function. This is specifically because creating a value of NonZero which is 0 is undefined behavior which is exploited by niche optimization. If you created your own `struct MyNonZero(u8)`, then you wouldn't need to mark MyNonZero::new_unchecked as unsafe because creating MyNonZero(0) is a "valid" value which doesn't trigger undefined behavior. The issue is that this could potentially allow creating a struct whose invariants are broken in safe rust. This breaks encapsulation, which means modules which use unsafe code (like `std::vec`) have no way to stop safe code from calling them with the invariants they rely on for safety broken. Let me give an example starting with an enum definition: // Assume std::vec has this definition struct Vec<T> { capacity: usize, length: usize, arena: * T } enum Example { First { capacity: usize, length: usize, arena: usize, discriminator: NonZero<u8> }, Second { vec: Vec<u8> } } Now assume the compiler has used niche optimization so that if the byte corresponding to `discriminator` is 0, then the enum is `Example::Second`, while if the byte corresponding to `discriminator` is not 0, then the enum is `Example::First` with discriminator being equal to its given non-zero value. Furthermore, assume that `Example::First`'s `capacity`, `length`, and `arena` fields are in the in the same position as the fields of the same name for `Example::Second.vec`. If we allow `fn NonZero::new_unchecked(u8) -> NonZero<u8>` to be a safe function, we can create an invalid Vec: fn main() { let evil = NonZero::new_unchecked(0); // We write as an Example::First, // but this is read as an Example::Second // because discriminator == 0 and niche optimization let first = Example::First { capacity: 9001, length: 9001, arena: 0x20202020, discriminator: evil } if let Example::Second{ vec: bad_vec } = first { // If the layout of Example is as I described, // and no optimizations occur, we should end up in here. // This writes 255 to address 0x20202020 bad_vec[0] = 255; } } So if we allowed new_unchecked to be safe, then it would be impossible to write a sound definition of Vec.
- Guthur 2y ago
  Because of cult like belief structures growing up around rust, it's clear as day for us on the outside, I see it from the evangelists in the company I work for "rust is faster and safer to develop with when compared to c++", I'm no c++ fan but it's obviously nonsense. I feel people took the comparison of rust to c and extrapolated to c++ which is blatantly disingenuous.
  - rcxdude 2y ago
    Care to explain the obvious, then? Rust is quite a lot nicer to write than C++ in my experience (and in fact, it seems like rust is most attractive to people who were already writing C++: people who still prefer C are a lot less likely to like Rust).
    - Guthur 2y ago
      There is nothing attractive about c++ or rust, I really don't understand how anyone can think so, it has to be some sort of Stockholm syndrome. Think about it, before you started programming what about your experiences would make you appreciate the syntax soup of rust and c++?
      - rcxdude 2y ago
        I dunno, there's not much about my previous experience that would indicate much one way or the other. I have found, though, that I tend to prefer slightly denser, heterogeneous code and syntax than average. Low-syntax languages like Haskell and Lisps make my head hurt because the code is so formless it becomes hard for me to parse, while languages with more syntax and symbols are easier (though, there is a limit, APL,k, etc, are a little far I find)
  - goku12 2y ago
    The cult that I see growing online a lot are those who are invested in attacking Rust for some reason, though their arguments often indicate that they haven't even tried it. I believe that we're focusing so much on Rust evangelists that we're neglecting the other end of the zealotry spectrum - the irrational haters. The Rust developers I meet are more interested in showing off their creations than in evangelizing the language. Even those on dedicated Rust forums are generally very receptive to other languages - you can see that in action on topics like goreleaser or Zig's comptime. And while you have already dismissed the other commenter's experience of finding Rust nicer than C++ to program in, I would like to add that I share their experience. I have nothing against C++, and I would like to relearn it so that I can contribute to some projects I like. But the reason why I started with Rust in 2013 was because of the memory-saftey issues I was facing with C++. There are features in Rust that I find surprisingly pleasant, even with 6 additional years of experience in Python. Your opinion that Rust is unpleasant to the programmer is not universal and its detractions are not nonsense. I appreciate the difficulty in learning Rust - especially getting past the stage of fighting the borrow checker. That's the reason why I don't promote Rust for immediate projects. However, I feel that the knowledge required to get past that stage is essential even for correct C and C++. Rust was easy for me to get started in, because of my background in digital electronics, C and C++. But once you get past that peak, Rust is full of very elegant abstractions that are similar to what's seen in Python. I know it works because I have trained js and python developers in Rust. And their feedback corroborates those assumptions about learning Rust.
Aurornis 2y ago
I see this subculture far more in online forums than with fellow Rust developers. Most often, the comments come from people who don’t even write much Rust. They either know just enough to be dangerous or they write other languages and feel like it’s a “gotcha” they can use against Rust.

brundolf 2y ago

Formally the team/docs are very clear, but I think many users of Rust miss that nuance and lump memory safety together with all the other features that create the "if it compiles it probably works" experience So I agree with the above comment that the title could be better, but I also understand why the author gave it this title

goku12 2y ago
I agree with most of your assertions. > ... with all the other features that create the "if it compiles it probably works" experience While it's true that Rust's core safety feature is almost exclusively about memory safety, I think it contributes more to the overall safety of the program. My professional background is more in electronics than in software. So when the Rust borrow checker complains, I tend to map them to nuances of the hardware and seek work-arounds for those problems. Those work-arounds often tend to be better restructuring of the code, with proper data isolation. While that may seem like hard work in the beginning, it's often better towards the end because of clarity and modularity it contributes to the code. Rust won't eliminate logical bugs or runtime bugs from careless coding. But it does encourage better coding practices. In addition, the strict, but expressive type system eliminates more bugs by encoding some extra constraints that are verified at compile time. (Yes, there are other languages that do this better). And while it is not guaranteed, I find Rust programs to just work if it compiles, more often than in the other languages I know. And the memory-safety system has a huge role in that experience.

ampere22 2y ago

If a C++ developer decides to use purely containers and smart pointers when starting a new project, how are they going to develop unsafe code? Containers like std::vector and smart pointers like std::unique_ptr seem to offer all of the same statically checked guarantees that Rust does. I just do not see how Rust is a superior language compared to modern C++

criddell 2y ago
C++ devs need to understand the difference between: Vec1[0]; Vec1.at(0); Even the at method isn’t statically checked. If you want static checking, you probably need to use std::array.
- pjmlp 2y ago
  Many also need to learn that there are configuration settings on their compilers that make those two cases the same, enabling bounds checking on operator[]().
  - criddell 2y ago
    Sure, but at() is guaranteed to throw an exception and operator[] can throw an exception when you go out of bounds. C++26 is tweaking this, but it's still going to differ implementation to implementation. At least that's my understanding of the situation. Happy to be corrected though.
ddulaney 2y ago
Unfortunately, operator[] on std::vector is inherently unsafe. You can potentially try to ban it (using at() instead), but that has its own problems. There’s a great talk by Louis Brandy called “Curiously Recurring C++ Bugs at Facebook” [0] that covers this really well, along with std::map’s operator[] and some more tricky bugs. An interesting question to ask if you try to watch that talk is: How does Rust design around those bugs, and what trade offs does it make? [0]: https://m.youtube.com/watch?v=lkgszkPnV8g https://m.youtube.com/watch?v=lkgszkPnV8g