5 ms·

I hear "people rarely use unsafe rust" quite a lot, but every time I see a project or library with C-like performance, there's a _lot_ of unsafe code in there.

I hear "people rarely use unsafe rust" quite a lot, but every time I see a project or library with C-like performance, there's a _lot_ of unsafe code in there. Treating bugs in unsafe code as not being bugs in rust code is kind of silly, also.

antirez 10mo ago
Exactly. You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change.
- kibwen 10mo ago
  For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code. The fact that the percentage is higher in the latter case doesn't change the fact that 95% of your codebase is just as safe as the Python project would be.
  - antirez 10mo ago
    A big amount of C code does not do anything unsafe as well, it calls other stuff, do loops, logic business, and so forth. It is also wrong to believe 100% of the C code is basically unsafe.
    - staticassertion 10mo ago
      You're swapping definitions of unsafe. Earlier you were referring to the `unsafe` keyword. Now you're using `unsafe` to refer to a property of code. This makes it easy to say things like "It is also wrong to believe 100% of the C code is basically unsafe" but you're just swapping definitions partway through the conversation.
      - broken-kebab 10mo ago
        What I see is that antirez claims that absence of "safe" (as syntax) in C lang doesn't automatically mean that all of C code is unsafe (as property). There's no swapping of definitions as I see it.
        b40d-48b2-979e 10mo ago
        Except that's a dishonest interpretation especially for someone of antirez's experience.
        staticassertion 10mo ago
        I think there's a very clear switch of usage happening. Maybe it's hard to see so I'll try to point out exactly where it happens and how you can spot it. First from antirez: > You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change. Use of the term `unsafe` here referring to the keyword / "blocks" of code. Note that this statement would be nonsensical if talking about `unsafe` as a property of code, certainly it would be inconsistent with the later unsafe since later it's claimed that C code is not inherently "unsafe" (therefor Rust would not be inherently "unsafe"). Kibwen staying on that definition here: > For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code. Here is the switch: > A big amount of C code does not do anything unsafe as well Complete shift to "unsafe" as being a property of code, no longer talking about the keyword or about blocks of code. You can spot it by just rewriting the sentences to use Rust instead of C. You can say: "A big amount of 'unsafe' Rust code does not do anything unsafe as well" "It is also wrong to believe 100% of the unsafe Rust code is basically unsafe." I think that makes this conflation of terms clear, because we're now talking about the properties of the code within an "unsafe" block or globally in C. Note how clear it is in these sentences that the term `unsafe` is being swapped, we can see this by referring to "rust in unsafe blocks" explicitly. This is just a change of definitions partway through the conversation. p.s. @Dang can you remove my rate limit? It's been years, I'm a good boy now :)
    - kibwen 10mo ago
      If so, then it should be trivial for someone to introduce something like Rust's `unsafe` keyword in C such that the unsafe operations can be explicitly annotated and encapsulated. Of course, it's not actually this trivial because what you're saying is incorrect. C is not equipped to enforce memory safety; even mundane C code is thoroughly suffused with operations that threaten to spiral off the rails into undefined behavior.
      - uecker 10mo ago
        It is not so hard to introduce a "safe" keyword in C. I have a patched GCC that does it. The subset of the language which can be used safety is a bit too small to be full replacement on its own, but also not that small.
    - amluto 10mo ago
      C lacks safe primitives or non-error-prone ways to build abstractions to refer to business objects. There are no safe string references, let along ways to safely manipulate strings. Want to iterate over or index into a result set? You can try to remember to put bounds checks into every API function. But even with explicit bounds checks, C has an ace up its sleeve. int cost_of_nth_item(int n) { if (n < 0 || n >= num_items) return -1; // error handling … } Safe, right? Not so fast, because if the caller has a code path that forgets to initialize the argument, it’s UB.
    - pdimitar 10mo ago
      Who is saying that 100% of C code is unsafe? It's potentially unsafe, as in: the mainstream compilers are unable to prove the code is memory-safe. Rust achieves a sizable but not complete victory on that front. I can't find the extreme claims that you seem to argue against.
    - marcosdumay 10mo ago
      Almost all of C code does unsafe things. Deferencing a pointer is unsafe, using the address of a variable is unsafe, adding signed integers is unsafe.
- gf000 10mo ago
  High performance is not an on/off target. Safe rust really lets you express a lot of software patterns in a "zero-cost" way. Sure, there are a few patterns where you may need to touch unsafe, but safe rust itself is not slow by any means.
pdimitar 10mo ago
For your last sentence, I believe topics are conflated here. Of course if one writes unsafe Rust and it leads to a CVE then that's on them. Who's denying that? On the other hand, having to interact with the part of the landscape that's written in C mandates the use of the `unsafe` keyword and not everyone is ideally equipped to be careful. I view the existence of `unsafe` as pragmatism; Rust never would have taken off without it. And if 5% of all Rust code is potentially unsafe, well, that's still much better than C where you can trivially introduce undefined behavior with many built-in constructs. Obviously we can't fix everything in one fell swoop.
- nec4b 10mo ago
  >>Of course if one writes unsafe Rust and it leads to a CVE then that's on them. >>Who's denying that? >>The recent bug in the Linux kernel Rust code, based on my understanding, was >>in unsafe code, and related to interop with C. So I wouldn't really classify >>it as a Rust bug. Sometimes it's good to read the whole thread.
  - pdimitar 10mo ago
    I did and it does not quite compute. That was glue code, related to interoperating with C. Not a "normal" everyday Rust code. It's an outlier. Helps to read and ingest context. Though I do agree that in the strictest of technical senses it's indeed a "Rust" bug, as in: bug in code written in Rust.
    - pclmulqdq 10mo ago
      The bug in question is in rust glue code that interfaces with a C library. It's not in the rust-C interface or on the C side. If you write python glue code that interfaces with numpy and there's a bug in your glue, it's a python bug not a numpy bug.
      - pdimitar 10mo ago
        I already agreed that technically it is indeed a bug in the Rust code. I would just contest that such a bug is representative is all. People in this thread seem way too eager to extrapolate which is not intellectually curious or fair.
selfmodruntime 9mo ago
There is a reason for this. A lot of libraries were written at a time when the Rust compiler either rejected sound and safe code so you have to reach for unsafe, or `core` didn't yet deliver safe abstractions.

antirez 10mo ago

Exactly. You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change.

kibwen 10mo ago
For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code. The fact that the percentage is higher in the latter case doesn't change the fact that 95% of your codebase is just as safe as the Python project would be.
- antirez 10mo ago
  A big amount of C code does not do anything unsafe as well, it calls other stuff, do loops, logic business, and so forth. It is also wrong to believe 100% of the C code is basically unsafe.
  - staticassertion 10mo ago
    You're swapping definitions of unsafe. Earlier you were referring to the `unsafe` keyword. Now you're using `unsafe` to refer to a property of code. This makes it easy to say things like "It is also wrong to believe 100% of the C code is basically unsafe" but you're just swapping definitions partway through the conversation.
    - broken-kebab 10mo ago
      What I see is that antirez claims that absence of "safe" (as syntax) in C lang doesn't automatically mean that all of C code is unsafe (as property). There's no swapping of definitions as I see it.
      - b40d-48b2-979e 10mo ago
        Except that's a dishonest interpretation especially for someone of antirez's experience.
      - staticassertion 10mo ago
        I think there's a very clear switch of usage happening. Maybe it's hard to see so I'll try to point out exactly where it happens and how you can spot it. First from antirez: > You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change. Use of the term `unsafe` here referring to the keyword / "blocks" of code. Note that this statement would be nonsensical if talking about `unsafe` as a property of code, certainly it would be inconsistent with the later unsafe since later it's claimed that C code is not inherently "unsafe" (therefor Rust would not be inherently "unsafe"). Kibwen staying on that definition here: > For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code. Here is the switch: > A big amount of C code does not do anything unsafe as well Complete shift to "unsafe" as being a property of code, no longer talking about the keyword or about blocks of code. You can spot it by just rewriting the sentences to use Rust instead of C. You can say: "A big amount of 'unsafe' Rust code does not do anything unsafe as well" "It is also wrong to believe 100% of the unsafe Rust code is basically unsafe." I think that makes this conflation of terms clear, because we're now talking about the properties of the code within an "unsafe" block or globally in C. Note how clear it is in these sentences that the term `unsafe` is being swapped, we can see this by referring to "rust in unsafe blocks" explicitly. This is just a change of definitions partway through the conversation. p.s. @Dang can you remove my rate limit? It's been years, I'm a good boy now :)
  - kibwen 10mo ago
    If so, then it should be trivial for someone to introduce something like Rust's `unsafe` keyword in C such that the unsafe operations can be explicitly annotated and encapsulated. Of course, it's not actually this trivial because what you're saying is incorrect. C is not equipped to enforce memory safety; even mundane C code is thoroughly suffused with operations that threaten to spiral off the rails into undefined behavior.
    - uecker 10mo ago
      It is not so hard to introduce a "safe" keyword in C. I have a patched GCC that does it. The subset of the language which can be used safety is a bit too small to be full replacement on its own, but also not that small.
  - amluto 10mo ago
    C lacks safe primitives or non-error-prone ways to build abstractions to refer to business objects. There are no safe string references, let along ways to safely manipulate strings. Want to iterate over or index into a result set? You can try to remember to put bounds checks into every API function. But even with explicit bounds checks, C has an ace up its sleeve. int cost_of_nth_item(int n) { if (n < 0 || n >= num_items) return -1; // error handling … } Safe, right? Not so fast, because if the caller has a code path that forgets to initialize the argument, it’s UB.
  - pdimitar 10mo ago
    Who is saying that 100% of C code is unsafe? It's potentially unsafe, as in: the mainstream compilers are unable to prove the code is memory-safe. Rust achieves a sizable but not complete victory on that front. I can't find the extreme claims that you seem to argue against.
  - marcosdumay 10mo ago
    Almost all of C code does unsafe things. Deferencing a pointer is unsafe, using the address of a variable is unsafe, adding signed integers is unsafe.
gf000 10mo ago
High performance is not an on/off target. Safe rust really lets you express a lot of software patterns in a "zero-cost" way. Sure, there are a few patterns where you may need to touch unsafe, but safe rust itself is not slow by any means.

pdimitar 10mo ago

For your last sentence, I believe topics are conflated here. Of course if one writes unsafe Rust and it leads to a CVE then that's on them. Who's denying that? On the other hand, having to interact with the part of the landscape that's written in C mandates the use of the `unsafe` keyword and not everyone is ideally equipped to be careful. I view the existence of `unsafe` as pragmatism; Rust never would have taken off without it. And if 5% of all Rust code is potentially unsafe, well, that's still much better than C where you can trivially introduce undefined behavior with many built-in constructs. Obviously we can't fix everything in one fell swoop.

nec4b 10mo ago
>>Of course if one writes unsafe Rust and it leads to a CVE then that's on them. >>Who's denying that? >>The recent bug in the Linux kernel Rust code, based on my understanding, was >>in unsafe code, and related to interop with C. So I wouldn't really classify >>it as a Rust bug. Sometimes it's good to read the whole thread.
- pdimitar 10mo ago
  I did and it does not quite compute. That was glue code, related to interoperating with C. Not a "normal" everyday Rust code. It's an outlier. Helps to read and ingest context. Though I do agree that in the strictest of technical senses it's indeed a "Rust" bug, as in: bug in code written in Rust.
  - pclmulqdq 10mo ago
    The bug in question is in rust glue code that interfaces with a C library. It's not in the rust-C interface or on the C side. If you write python glue code that interfaces with numpy and there's a bug in your glue, it's a python bug not a numpy bug.
    - pdimitar 10mo ago
      I already agreed that technically it is indeed a bug in the Rust code. I would just contest that such a bug is representative is all. People in this thread seem way too eager to extrapolate which is not intellectually curious or fair.

selfmodruntime 9mo ago

There is a reason for this. A lot of libraries were written at a time when the Rust compiler either rejected sound and safe code so you have to reach for unsafe, or `core` didn't yet deliver safe abstractions.