4 ms·

I’ve said it before and I’ll say it again, although I think it’s an unpopular opinion: Rust introduces unsafe code (at a minimum through crates). The rust com

I’ve said it before and I’ll say it again, although I think it’s an unpopular opinion: Rust introduces unsafe code (at a minimum through crates). The rust community hates that people use C++ when they could use a memory safe language, so why are they introducing memory unsafe to something that a GC works fine? It’s like their opinion of memory safety as a necessity totally flips the second rust is the unsafe one.

ameliaquining 4y ago
All languages have memory unsafety somewhere in the stack.
- mr_00ff00 4y ago
  This just makes no sense to me, then why try to replace C++? After all, all languages are memory unsafe. Rust let’s you write unsafe code, that’s so different than say python.
  - rom-antics 4y ago
    Python lets you write unsafe code. https://wiki.python.org/moin/CrashingPython https://wiki.python.org/moin/CrashingPython Does that mean it's no safer than C++?
    - mr_00ff00 4y ago
      What? Those aren’t memory exploitable bugs. And no I am not, you are saying that. I think python is way safer than either, you seem to think because you can crash a python program that means the memory vulnerabilities of rust are justified.
      - rom-antics 4y ago
        Crashes are just security holes that nobody has crafted an exploit for yet.
        mr_00ff00 4y ago
        GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. And you didn’t address my second point.
        rom-antics 4y ago
        > GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. All of the work Python does at runtime with a GC, Rust does at compile time with the borrow checker. GC is orthogonal to the idea of memory safety. > And you didn’t address my second point. I don't know what you expect. It's a semantically empty statement and thus unfalsifiable. You can flip it around without changing the truth or the meaning: > you seem to think because you can crash a Rust program that means the memory vulnerabilities of Python are justified.
      - ameliaquining 4y ago
        It's not just crashes. Python's ctypes API can do anything that unsafe Rust can do, including the parts that permit arbitrary code execution vulnerabilities.
  - ameliaquining 4y ago
    C++ is pervasively memory-unsafe; a bug in any part of a C++ codebase can easily cause undefined behavior, such that you can't isolate the memory-unsafe parts and apply extra assurance techniques to them. Most modern garbage-collected languages do let you do this, as does Rust.
rom-antics 4y ago
Every language has unsafe bits if you look deep enough. CPython and Java's garbage collector are written in C, and we have ctypes and JNI, but I think most people would still consider those memory safe languages. The important question is: is there a well-defined safety boundary, somewhere between the CPU and your application code, where memory is guaranteed* not to be corrupted and the programmer is freed from worrying about low-level bugs like segfaults? *assuming no outside bugs such as CPU bugs, bugs in the GC, or bugs in an unsafe block
- mr_00ff00 4y ago
  This doesn’t make sense. So rust let’s you write unsafe code, and now that’s the same as any language that calls C in any way? Why replace C++ then? After all, rust is just as unsafe by your definition. Having a language that is default safe and can only be unsafe in rare situations is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary.
  - rom-antics 4y ago
    > Having a language that is default safe and can only be unsafe in rare situations This describes both Python and Rust. They are default safe, with escape hatches (ctypes or unsafe blocks) for rare situations. Writing unsafe code in Rust should be as rare as using ctypes in Python. > is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary. Python lets libs use ctypes to poke at raw memory. Solution: avoid those libraries Rust lets libs use unsafe blocks. Solution: avoid those libraries (and optionally use tools like cargo-geiger or forbid(unsafe) if you care enough
    - mr_00ff00 4y ago
      If you don’t seem a parallel between what you just said: “just use these tools to catch the unsafe parts of rust” and the C++ crowd saying “just use these tools or do these things to catch the unsafe parts of cpp” there’s no point in continuing this discussion. Python ctypes are not at all as common as rust unsafe code and geiger only goes so deep in search for unsafe code if I remember correctly.
burntsushi 4y ago
Isn't it obvious? The position is not against the use of code that might cause UB, it's against making that the default everywhere. In Rust, unsafe is opt in and can be encapsulated. That's the key bit.

ameliaquining 4y ago

All languages have memory unsafety somewhere in the stack.

mr_00ff00 4y ago
This just makes no sense to me, then why try to replace C++? After all, all languages are memory unsafe. Rust let’s you write unsafe code, that’s so different than say python.
- rom-antics 4y ago
  Python lets you write unsafe code. https://wiki.python.org/moin/CrashingPython https://wiki.python.org/moin/CrashingPython Does that mean it's no safer than C++?
  - mr_00ff00 4y ago
    What? Those aren’t memory exploitable bugs. And no I am not, you are saying that. I think python is way safer than either, you seem to think because you can crash a python program that means the memory vulnerabilities of rust are justified.
    - rom-antics 4y ago
      Crashes are just security holes that nobody has crafted an exploit for yet.
      - mr_00ff00 4y ago
        GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. And you didn’t address my second point.
        rom-antics 4y ago
        > GCs do various resource clean up that mean certain bugs are not exploitable. Rust does not have that. All of the work Python does at runtime with a GC, Rust does at compile time with the borrow checker. GC is orthogonal to the idea of memory safety. > And you didn’t address my second point. I don't know what you expect. It's a semantically empty statement and thus unfalsifiable. You can flip it around without changing the truth or the meaning: > you seem to think because you can crash a Rust program that means the memory vulnerabilities of Python are justified.
    - ameliaquining 4y ago
      It's not just crashes. Python's ctypes API can do anything that unsafe Rust can do, including the parts that permit arbitrary code execution vulnerabilities.
- ameliaquining 4y ago
  C++ is pervasively memory-unsafe; a bug in any part of a C++ codebase can easily cause undefined behavior, such that you can't isolate the memory-unsafe parts and apply extra assurance techniques to them. Most modern garbage-collected languages do let you do this, as does Rust.

rom-antics 4y ago

Every language has unsafe bits if you look deep enough. CPython and Java's garbage collector are written in C, and we have ctypes and JNI, but I think most people would still consider those memory safe languages. The important question is: is there a well-defined safety boundary, somewhere between the CPU and your application code, where memory is guaranteed* not to be corrupted and the programmer is freed from worrying about low-level bugs like segfaults? *assuming no outside bugs such as CPU bugs, bugs in the GC, or bugs in an unsafe block

mr_00ff00 4y ago
This doesn’t make sense. So rust let’s you write unsafe code, and now that’s the same as any language that calls C in any way? Why replace C++ then? After all, rust is just as unsafe by your definition. Having a language that is default safe and can only be unsafe in rare situations is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary.
- rom-antics 4y ago
  > Having a language that is default safe and can only be unsafe in rare situations This describes both Python and Rust. They are default safe, with escape hatches (ctypes or unsafe blocks) for rare situations. Writing unsafe code in Rust should be as rare as using ctypes in Python. > is way better than one that lets libraries write unsafe code, which is better than a language with no safe boundary. Python lets libs use ctypes to poke at raw memory. Solution: avoid those libraries Rust lets libs use unsafe blocks. Solution: avoid those libraries (and optionally use tools like cargo-geiger or forbid(unsafe) if you care enough
  - mr_00ff00 4y ago
    If you don’t seem a parallel between what you just said: “just use these tools to catch the unsafe parts of rust” and the C++ crowd saying “just use these tools or do these things to catch the unsafe parts of cpp” there’s no point in continuing this discussion. Python ctypes are not at all as common as rust unsafe code and geiger only goes so deep in search for unsafe code if I remember correctly.

burntsushi 4y ago

Isn't it obvious? The position is not against the use of code that might cause UB, it's against making that the default everywhere. In Rust, unsafe is opt in and can be encapsulated. That's the key bit.