3 ms·

...at which point the code written in C will suffer from BOTH categories of bug, while code written in any language whose compiler guarantees memory safety will

by mcherm 3y ago

...at which point the code written in C will suffer from BOTH categories of bug, while code written in any language whose compiler guarantees memory safety will not. Guaranteeing memory safety isn't just an overhyped benefit meaningful only to Rust fanboys. It is also one important reason why much code is written in Java, Python, or JavaScript. It is a valuable property for any language to have.

bombolo 3y ago
Rust doesn't guarantee memory safety in general… it is better at it than C for sure, but not impossible to have bugs there too. The 100% certainty you use to claim it's absolutely memory safe is the essence of the problem with the rust fanboys.
- winter_blue 3y ago
  I think you might need to define what exactly you mean by "memory safe". There is an entire class of bugs common to C and C++ that absolutely never happen in JVM languages, CLR languages, Rust, etc. This particular class of bugs of bugs never happen by design, because the language design simply does not permit them to occur ever.¹ ¹ I am obviously of course excluding bugs/exploits/unintentional-loopholes here that are in the JVM or CLR, or in the Rust compiler itself, that permit a program to "break out of its box", so to speak.
  - bombolo 3y ago
    https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
    - winter_blue 3y ago
      This is a super-well-known issue with reference counting in general. It would be something to deal with anywhere one uses reference counting exclusively. For example, this is a problem in Swift as well: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/#Strong-Reference-Cycles-Between-Class-Instances https://docs.swift.org/swift-book/documentation/the-swift-pr... Does that mean Swift is unsafe? No. All this does is create the potential for a memory leak. Which is nowhere close to being in the same category as a buffer overflow exploit. Also, I suppose one could write a garbage-collected pointer library for Rust, which adds cycle detection (and auto-deletion) on top of ARC.

by mcherm 3y ago

bombolo 3y ago

Rust doesn't guarantee memory safety in general… it is better at it than C for sure, but not impossible to have bugs there too. The 100% certainty you use to claim it's absolutely memory safe is the essence of the problem with the rust fanboys.

winter_blue 3y ago
I think you might need to define what exactly you mean by "memory safe". There is an entire class of bugs common to C and C++ that absolutely never happen in JVM languages, CLR languages, Rust, etc. This particular class of bugs of bugs never happen by design, because the language design simply does not permit them to occur ever.¹ ¹ I am obviously of course excluding bugs/exploits/unintentional-loopholes here that are in the JVM or CLR, or in the Rust compiler itself, that permit a program to "break out of its box", so to speak.
- bombolo 3y ago
  https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
  - winter_blue 3y ago
    This is a super-well-known issue with reference counting in general. It would be something to deal with anywhere one uses reference counting exclusively. For example, this is a problem in Swift as well: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/#Strong-Reference-Cycles-Between-Class-Instances https://docs.swift.org/swift-book/documentation/the-swift-pr... Does that mean Swift is unsafe? No. All this does is create the potential for a memory leak. Which is nowhere close to being in the same category as a buffer overflow exploit. Also, I suppose one could write a garbage-collected pointer library for Rust, which adds cycle detection (and auto-deletion) on top of ARC.