4 ms·

all those advantages and disadvantages you list are basically insignificant compared to rust being memory safe by default and c/c++ not. governments aren't bugg

all those advantages and disadvantages you list are basically insignificant compared to rust being memory safe by default and c/c++ not. governments aren't bugging projects about any of those, but are about memory safety.

milesrout 2y ago
You might think so. I strongly disagree. I think Rust's supposed memory safety advantages are a distraction. If people really cared about that above all else they would use a memory-safe language, which Rust is not, such as Java or Python or Haskell or something. There are tons. Governments aren't "bugging" anyone about memory safety and if they were, they wouldn't want you to use Rust. Rust isn't memory-safe.
- oneshtein 2y ago
  Safe Rust is memory-safe enough for practical needs, while maintaining top performance.
  - menaerus 2y ago
    Is it still safe even if it depends on the dependencies which are not safe?
    - kobebrookskC3 2y ago
      seems pretty safe in practice https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html#fnref3 https://security.googleblog.com/2024/09/eliminating-memory-s...
      - menaerus 2y ago
        I know it's an unpopular opinion but tbh those Google security blogs always read more as a marketing material than engineering effort. Why I think so it's because statistics always has two side of the coins - if you want to make something look better or worse than it really is, it's trivial to do so. There's simply not enough data or methodology or different angles taken for me personally to take these blogs as a very relevant source of information but YMMV. We are all different.
    - whytevuhuni 2y ago
      Note that memory-safe languages like Java and Python will also depend on libraries which are not safe, e.g. in their implementation of the interpreter/VM, standard library, native libraries like numpy, etc. In practice unsafe Rust tends to be less than 1% of the code (or around 5% in low-level things like kernels), which is a similar ratio of trusted/untrusted code. The top-level application code is generally expected to have 0%.
      - milesrout 2y ago
        This statistic is based on the lines of code bounded by the "unsafe" keyword but that is not the full picture. Unsafe code relies for its safety on the logical correctness of safe code. In theory, as "proper practice", the trust boundary should be the crate. In other words, the safety of a particular "unsafe" block should be verifiable by checking the correctness of code within the same crate. In practice, this is not true: much unsafe code relies for safety on correctness properties in external code, especially from the standard library, like the fact that "Vec" stores elements contiguously in memory in order of index. That isn't to say the concept is useless. But it is not the case that you just need to inspect code marked "unsafe". A change to code not marked "unsafe" can break the invariants and assumptions that unsafe blocks elsewhere rely on.
        whytevuhuni 2y ago
        That's right, unsafety extends to the whole module, and anything else that relies on the module's internal implementation. Generally all the way up to the abstraction's public API, whatever that abstraction is (a Vec, a Mutex, etc). But it's nevertheless still not different from other languages that are deemed memory safe.
        kobebrookskC3 2y ago
        modules are meant to be the boundary for a safe abstraction, but sometimes you get fun holes like https://github.com/rust-lang/rust/issues/128872 https://github.com/rust-lang/rust/issues/128872 where you can implement Copy for a type in a different module in the same crate, even if the fields are private
    - oneshtein 2y ago
      Any and all safe code depends on unsafe code to do something, including Java and Python. Yep, unsafe code may contains bugs, but their surface is much smaller, so, at same ratio of bugs to code, numbers of bugs is much smaller.
      - menaerus 2y ago
        If you're open to a bit different and perhaps thought provoking perspective let me say that for your hypothesis to be true we would need to assume that the distribution of memory-safety bugs is uniform across the codebase. From my experience this is not true, it usually follows uni-modal or at most bi-modal distribution, so it follows that the surface is not much smaller.
- kobebrookskC3 2y ago
  > If people really cared about that above all else they would use a memory-safe language, which Rust is not, such as Java or Python or Haskell or something. people already use languages like java or python or js in most cases! it's only in rare cases it made sense to write stuff in c or c++. now with rust, that niche becomes even smaller. > Governments aren't "bugging" anyone about memory safety idk this report sounds like bugging from governments (plural) to me: https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf https://www.cisa.gov/sites/default/files/2023-12/The-Case-fo... no one who isn't being obtuse would say rust isn't memory safe. the linked report also deems rust a memory safe language.

milesrout 2y ago

You might think so. I strongly disagree. I think Rust's supposed memory safety advantages are a distraction. If people really cared about that above all else they would use a memory-safe language, which Rust is not, such as Java or Python or Haskell or something. There are tons. Governments aren't "bugging" anyone about memory safety and if they were, they wouldn't want you to use Rust. Rust isn't memory-safe.

oneshtein 2y ago
Safe Rust is memory-safe enough for practical needs, while maintaining top performance.
- menaerus 2y ago
  Is it still safe even if it depends on the dependencies which are not safe?
  - kobebrookskC3 2y ago
    seems pretty safe in practice https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html#fnref3 https://security.googleblog.com/2024/09/eliminating-memory-s...
    - menaerus 2y ago
      I know it's an unpopular opinion but tbh those Google security blogs always read more as a marketing material than engineering effort. Why I think so it's because statistics always has two side of the coins - if you want to make something look better or worse than it really is, it's trivial to do so. There's simply not enough data or methodology or different angles taken for me personally to take these blogs as a very relevant source of information but YMMV. We are all different.
  - whytevuhuni 2y ago
    Note that memory-safe languages like Java and Python will also depend on libraries which are not safe, e.g. in their implementation of the interpreter/VM, standard library, native libraries like numpy, etc. In practice unsafe Rust tends to be less than 1% of the code (or around 5% in low-level things like kernels), which is a similar ratio of trusted/untrusted code. The top-level application code is generally expected to have 0%.
    - milesrout 2y ago
      This statistic is based on the lines of code bounded by the "unsafe" keyword but that is not the full picture. Unsafe code relies for its safety on the logical correctness of safe code. In theory, as "proper practice", the trust boundary should be the crate. In other words, the safety of a particular "unsafe" block should be verifiable by checking the correctness of code within the same crate. In practice, this is not true: much unsafe code relies for safety on correctness properties in external code, especially from the standard library, like the fact that "Vec" stores elements contiguously in memory in order of index. That isn't to say the concept is useless. But it is not the case that you just need to inspect code marked "unsafe". A change to code not marked "unsafe" can break the invariants and assumptions that unsafe blocks elsewhere rely on.
      - whytevuhuni 2y ago
        That's right, unsafety extends to the whole module, and anything else that relies on the module's internal implementation. Generally all the way up to the abstraction's public API, whatever that abstraction is (a Vec, a Mutex, etc). But it's nevertheless still not different from other languages that are deemed memory safe.
        kobebrookskC3 2y ago
        modules are meant to be the boundary for a safe abstraction, but sometimes you get fun holes like https://github.com/rust-lang/rust/issues/128872 https://github.com/rust-lang/rust/issues/128872 where you can implement Copy for a type in a different module in the same crate, even if the fields are private
  - oneshtein 2y ago
    Any and all safe code depends on unsafe code to do something, including Java and Python. Yep, unsafe code may contains bugs, but their surface is much smaller, so, at same ratio of bugs to code, numbers of bugs is much smaller.
    - menaerus 2y ago
      If you're open to a bit different and perhaps thought provoking perspective let me say that for your hypothesis to be true we would need to assume that the distribution of memory-safety bugs is uniform across the codebase. From my experience this is not true, it usually follows uni-modal or at most bi-modal distribution, so it follows that the surface is not much smaller.
kobebrookskC3 2y ago
> If people really cared about that above all else they would use a memory-safe language, which Rust is not, such as Java or Python or Haskell or something. people already use languages like java or python or js in most cases! it's only in rare cases it made sense to write stuff in c or c++. now with rust, that niche becomes even smaller. > Governments aren't "bugging" anyone about memory safety idk this report sounds like bugging from governments (plural) to me: https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf https://www.cisa.gov/sites/default/files/2023-12/The-Case-fo... no one who isn't being obtuse would say rust isn't memory safe. the linked report also deems rust a memory safe language.