4 ms·

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 cha

by antirez 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
        Except that's a dishonest interpretation especially for someone of antirez's experience.
      - staticassertion 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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.

by antirez 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
      Except that's a dishonest interpretation especially for someone of antirez's experience.
    - staticassertion 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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 9mo 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.