6 ms·

Unsafe Rust is significantly harder than C, with complex rules that are not fully specified. But luckily you don't have to write a lot of it. And the bit you ne

Unsafe Rust is significantly harder than C, with complex rules that are not fully specified. But luckily you don't have to write a lot of it. And the bit you need can either come from battle-tested libraries or be contained to it's own module where you can rigorously test and fuzz it. And the tooling available for that is pretty good. The article shows good examples of that. There is some work on making unsafe rust safer, or at least easier to get right. But those are significant undertakings that will take years to pay off. On the other hand safe rust is so much easier than correct C that I don't particularly mind the tradeoff.

kazinator 2y ago
Safe Rust looks absolutely painful painful compared to other safe languages. Correct C is not actually hard to write. It can be somewhat hard to convince oneself that it's right. That's an important difference. Not all C has to be correct. If it's experimental or exploratory code that'll be thrown away. If that just works on one machine or on particular inputs that you care about, or it only certain specific environmental conditions, that can be fine. Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems.
- tptacek 2y ago
  When people talk about not needing to write much unsafe Rust, they mean that in any large-scale system, there are probably only a couple hotspots that are complicated enough to need the escape hatch from the Rust safety rules; you write the unsafe code, you give it an interface to the rest of the code, you carefully validate the unsafe code, and you're good to go. They don't mean that you write unsafe Rust code for experimental or exploratory code that will be thrown away. You could do that, but it's not common. More importantly: this approach of parsimoniously writing unsafe code in a larger-scale safe system does not work in C/C++. Memory safety issues can (and do) crop up all over your system, not just in the small "unsafe" parts you validate carefully.
  - steveklabnik 2y ago
    Writing unsafe Rust is enough of a pain in the butt (partially thanks to some syntactic salt that comes from the early days that probably should be removed but isn't being dealt with any time soon as far as I know) that it would be harder to prototype in unsafe Rust than safe Rust, IMHO.
    - Ygg2 2y ago
      I'm curious. What syntaxic salt?
      - steveklabnik 2y ago
        Needing explicit deref for raw pointers. (*ptr).bar() instead of ptr.bar() like if it ptr was a reference or adding something like ptr~bar() so at least you still know it’s a raw pointer deref but is at least nearly the same as a reference.
  - kazinator 2y ago
    Write the unsafe code easily in C, and write the rest of it in an easy-to-use language, and you're good to go.
    - tptacek 2y ago
      That's a valid strategy, but it's harder to write "unsafe-safe" code in C than people think it is. We just did a podcast episode about this with results from the Android team: https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/ https://securitycryptographywhatever.com/2024/10/15/a-little... Even with careful rules and oversight and secure coding idioms and library exclusions and fuzzing, the rate of memory safety defects in C/C++ code is still pretty high.
      - hedgehog 2y ago
        I'm not sure I've met anyone with significant application security experience who would claim writing correct C is anything less than very challenging. It's not just memory safety, even basic features like iterable collections make code easier to write while at the same time avoiding potential bugs (vs C for loops in this case).
- steveklabnik 2y ago
  Safe Rust takes some time to learn, but once you do, is quite pleasant to write. It is true that it takes some time to get over that hump though. Google found that it was three to six months, but after that, there was no productivity penalty. Rust offers tons of tools that are very useful for correctness outside of memory safety. I hope to never program in a language without sum types ever again, if possible.
  - rc00 2y ago
    You keep referencing Google's clearly flawed and asymmetric marketing about Rust. It is really unsightly. It has been thoroughly debunked nearly everywhere it was reported but here is a 10 minute recap of some of the clear flaws: https://www.youtube.com/watch?v=vB3ACXSesGo https://www.youtube.com/watch?v=vB3ACXSesGo The summary is that the research that you reference was not done in good faith.
    - steveklabnik 2y ago
      I like prime but just because he says something doesn't mean it's true. Repeating his claims in text form would be much more useful than linking to a video. I am not anti-video, but for example, I am out in public right now, and cannot watch it, and therefore can't meaningfully respond.
      - rc00 2y ago
        The video is worth a watch before responding. I'll try to summarize but it is unfair to the content. (I specifically opted for it over some others due to its brevity.) In all, the statement from Google lacks context and due diligence. Some bullets: * Experience levels in C++ and Rust are not equivalent. The experience gap between C++ and Rust developers can skew results, as C++ has been around much longer, affecting developer proficiency and code complexity. * Comparison of codebases: legacy C++ vs. greenfield Rust. Comparing a mature C++ codebase with a new Rust project is like comparing apples to oranges; age and complexity can impact productivity metrics significantly. * Measurement metrics can be misleading. The metrics used to determine productivity often lack depth, failing to account for feature complexity or development duration. * Organizations have asymmetric composition of resources. The management style and communication within teams can heavily influence productivity, indicating that not all teams function under the same conditions.
- kelnos 2y ago
  > Correct C is not actually hard to write. Ugh, not this again. Yes it is. It's hard. Veteran C programmers (I include myself in this category), even with compiler warnings, linters, and address sanitizers, still make mistakes all the time. > Not all C has to be correct. If it's experimental or exploratory code that'll be thrown away. If that just works on one machine or on particular inputs that you care about, or it only certain specific environmental conditions, that can be fine. So what? That's not the kind of code we're talking about. > Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems. That's either whataboutism or a straw man. No one is claiming that languages that help avoid common C memory-related bugs like out-of-bounds access, use-after-free, memory leaks, etc. will also somehow magically make all your logic errors go away too.
  - kazinator 2y ago
    > still make mistakes all the time Even veteran eaters bite their tongue or lip once in while. That doesn't mean eating is hard. > No one is claiming Only about 3 out of 4 Rust advocates. > That's not the kind of code we're talking about. We should talk about all code. Code that gets thrown away, rewritten, or improved from prototype to production. It is relevant to productivity. If I'm going to throw away some code to get to the code I want, it will be an extra waste of time if it is difficult to write.
    - gauge_field 2y ago
      I am not sure if Rust advocates tell that it will "magically" fix logic errors. What I hear they say is rather more precise terms: Stronger Type system, and memory safety, forcing more explicit design (e.g. no function overload). Whether this is true or not is another discussion to have. In my experience, it helps to have stronger type system regardless of any language of comparison if you want to avoid logic errors.
      - kazinator 2y ago
        Not just logic errors but their problems in life, or something.
- stouset 2y ago
  > Safe Rust looks absolutely painful painful compared to other safe languages. It really isn't. It's quite nice to use. The big hangup is that Rust "wants" you to structure your programs according to a certain philosophy. Unfortunately the compiler can't teach you that approach directly, but can only complain when you write programs that don't abide by it. In my experience, following this design philosophy benefits even outside of memory safety, and I now write code following these principles in every language. > Correct C is not actually hard to write. Quite literally all of the available evidence strongly disagrees with this conclusion. > Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems. This is true, but C lack tools to help with any of them. Fixing memory safety and overflows is in and of itself an enormous win, but Rust also has other tools that assist in program correctness (sum types being a huge one).
  - kazinator 2y ago
    > Quite literally all of the available evidence strongly disagrees with this conclusion. Easy to write is not the same thing as easy to prove. It may be hard to show that some C program is correct, but when that is done, that doesn't change that it was easy to write (if that had been the case). C is actually "unreasonably effective". You can't just look at the problems; the overall picture is that a lot of large and complicated, yet well-working systems have been achieved in C. They may not be correct, but are "correct enough".
    - stouset 2y ago
      The number of large C programs which have been repeatedly proven to be incorrect in practice is essentially 100%. Still, C is unreasonably effective. A lot of large and complicated, yet mostly well-working (modulo regular CVEs) systems have been achieved in C. And that’s truly wonderful. I cut my teeth on C nearly 30 years ago and I still hold a soft spot in my heart for it. But other languages these days are even more unreasonably effective. They need fewer lines of code to achieve the same results and they have fewer security vulnerabilities and logic bugs per line as well.
- rowanG077 2y ago
  > Correct C is not actually hard to write. I would advise to you not say such blatantly false things. You paint yourself either as a liar or as unqualified. C has been proven time and time again to be almost impossible to write correctly. Even top tier programmers like djb cannot write safe C.
  - kazinator 2y ago
    Nobody can write "safe C" because C is inherently not safe. See my other comment about it. Safe means something like "if the program breaks some semantic rule, it will be caught and diagnosed". It's not a statement about the program being correct or not, but the consequences of if it were to be incorrect. Even tiny, trivial programs have the potential to be incorrect without diagnosis. > C has been proven time and time again to be almost impossible to write correctly. Silly hyperbole.
    - rowanG077 2y ago
      Without writing safe C you cannot write correct C. If your C is unsafe it is incorrect by definition.
      - deleted 2y ago
        [deleted]
      - kazinator 2y ago
        That is obviously untrue by the definition of unsafe that I've been explicitly using. I've been sticking with the concept of unsafe language, whereas you're talking about an unsafe program. The two are related. An unsafe program misbehaves when given bad inputs. It's behavior is undefined. An unsafe language is an unsafe program with regard to bad inputs, which consist of certain kinds of incorrect programs. (Those which are not diagnosed). It's easy to write unsafe programs in unsafe languages. If we only focus on the program's functional requirements and none of them speak about what to do with bad inputs or in bad situations, we can end up with a program which is perfectly correct but unsafe. It will behave as specified on the correct inputs. If you happen to be advocating Rust due to misunderstanding this kind of material, you're in it for the wrong reasons.
- signa11 2y ago
  yup, after some experience, memory safety becomes kinda easy to get right. integer safety on the other hand is pretty hard, and non-trivial to get right unfortunately.
- f1shy 2y ago
  There are two big commandments of the modern programming religion: - Type safety - "Memory safety" We have to understand it: it is religion. No science. in 10 years maybe somebody start realising, that even with the 2 sw can still be very bad. And those 2 are not silver bullets... until then... patience.
WalterBright 2y ago
> On the other hand safe rust is so much easier than correct C that I don't particularly mind the tradeoff. D isn't Rust, but my personal style has gravitated towards the borrow checker rules anyway. It wouldn't be hard at all to do it in C, either. C's biggest security failing, however, is the lack of array bounds checking. It's always the #1 cause of security bugs in the field, by a wide margin. None of the workarounds in Standard C are attractive. I do not understand why the C committee adds all these bits and pieces of new features, and does not fix that problem. It's not like it's hard: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html The solution has been out there for 15 years now.
- Gibbon1 2y ago
  The standards people won't even add a standard buffer or slice to the language. I kinda cry every time I see a new api with foo(void *src, int sz) signatures.
  - rurban 2y ago
    The standard people won't even add proper string support, besides their weak support for null-terminated buffers. Unicode strings have very special rules for searching, comparison and upper/lowercasing. And they are usually UTF-8 encoded.
justincredible 2y ago
[dead]

kazinator 2y ago

Safe Rust looks absolutely painful painful compared to other safe languages. Correct C is not actually hard to write. It can be somewhat hard to convince oneself that it's right. That's an important difference. Not all C has to be correct. If it's experimental or exploratory code that'll be thrown away. If that just works on one machine or on particular inputs that you care about, or it only certain specific environmental conditions, that can be fine. Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems.

tptacek 2y ago
When people talk about not needing to write much unsafe Rust, they mean that in any large-scale system, there are probably only a couple hotspots that are complicated enough to need the escape hatch from the Rust safety rules; you write the unsafe code, you give it an interface to the rest of the code, you carefully validate the unsafe code, and you're good to go. They don't mean that you write unsafe Rust code for experimental or exploratory code that will be thrown away. You could do that, but it's not common. More importantly: this approach of parsimoniously writing unsafe code in a larger-scale safe system does not work in C/C++. Memory safety issues can (and do) crop up all over your system, not just in the small "unsafe" parts you validate carefully.
- steveklabnik 2y ago
  Writing unsafe Rust is enough of a pain in the butt (partially thanks to some syntactic salt that comes from the early days that probably should be removed but isn't being dealt with any time soon as far as I know) that it would be harder to prototype in unsafe Rust than safe Rust, IMHO.
  - Ygg2 2y ago
    I'm curious. What syntaxic salt?
    - steveklabnik 2y ago
      Needing explicit deref for raw pointers. (*ptr).bar() instead of ptr.bar() like if it ptr was a reference or adding something like ptr~bar() so at least you still know it’s a raw pointer deref but is at least nearly the same as a reference.
- kazinator 2y ago
  Write the unsafe code easily in C, and write the rest of it in an easy-to-use language, and you're good to go.
  - tptacek 2y ago
    That's a valid strategy, but it's harder to write "unsafe-safe" code in C than people think it is. We just did a podcast episode about this with results from the Android team: https://securitycryptographywhatever.com/2024/10/15/a-little-bit-of-rust-goes-a-long-way/ https://securitycryptographywhatever.com/2024/10/15/a-little... Even with careful rules and oversight and secure coding idioms and library exclusions and fuzzing, the rate of memory safety defects in C/C++ code is still pretty high.
    - hedgehog 2y ago
      I'm not sure I've met anyone with significant application security experience who would claim writing correct C is anything less than very challenging. It's not just memory safety, even basic features like iterable collections make code easier to write while at the same time avoiding potential bugs (vs C for loops in this case).
steveklabnik 2y ago
Safe Rust takes some time to learn, but once you do, is quite pleasant to write. It is true that it takes some time to get over that hump though. Google found that it was three to six months, but after that, there was no productivity penalty. Rust offers tons of tools that are very useful for correctness outside of memory safety. I hope to never program in a language without sum types ever again, if possible.
- rc00 2y ago
  You keep referencing Google's clearly flawed and asymmetric marketing about Rust. It is really unsightly. It has been thoroughly debunked nearly everywhere it was reported but here is a 10 minute recap of some of the clear flaws: https://www.youtube.com/watch?v=vB3ACXSesGo https://www.youtube.com/watch?v=vB3ACXSesGo The summary is that the research that you reference was not done in good faith.
  - steveklabnik 2y ago
    I like prime but just because he says something doesn't mean it's true. Repeating his claims in text form would be much more useful than linking to a video. I am not anti-video, but for example, I am out in public right now, and cannot watch it, and therefore can't meaningfully respond.
    - rc00 2y ago
      The video is worth a watch before responding. I'll try to summarize but it is unfair to the content. (I specifically opted for it over some others due to its brevity.) In all, the statement from Google lacks context and due diligence. Some bullets: * Experience levels in C++ and Rust are not equivalent. The experience gap between C++ and Rust developers can skew results, as C++ has been around much longer, affecting developer proficiency and code complexity. * Comparison of codebases: legacy C++ vs. greenfield Rust. Comparing a mature C++ codebase with a new Rust project is like comparing apples to oranges; age and complexity can impact productivity metrics significantly. * Measurement metrics can be misleading. The metrics used to determine productivity often lack depth, failing to account for feature complexity or development duration. * Organizations have asymmetric composition of resources. The management style and communication within teams can heavily influence productivity, indicating that not all teams function under the same conditions.
kelnos 2y ago
> Correct C is not actually hard to write. Ugh, not this again. Yes it is. It's hard. Veteran C programmers (I include myself in this category), even with compiler warnings, linters, and address sanitizers, still make mistakes all the time. > Not all C has to be correct. If it's experimental or exploratory code that'll be thrown away. If that just works on one machine or on particular inputs that you care about, or it only certain specific environmental conditions, that can be fine. So what? That's not the kind of code we're talking about. > Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems. That's either whataboutism or a straw man. No one is claiming that languages that help avoid common C memory-related bugs like out-of-bounds access, use-after-free, memory leaks, etc. will also somehow magically make all your logic errors go away too.
- kazinator 2y ago
  > still make mistakes all the time Even veteran eaters bite their tongue or lip once in while. That doesn't mean eating is hard. > No one is claiming Only about 3 out of 4 Rust advocates. > That's not the kind of code we're talking about. We should talk about all code. Code that gets thrown away, rewritten, or improved from prototype to production. It is relevant to productivity. If I'm going to throw away some code to get to the code I want, it will be an extra waste of time if it is difficult to write.
  - gauge_field 2y ago
    I am not sure if Rust advocates tell that it will "magically" fix logic errors. What I hear they say is rather more precise terms: Stronger Type system, and memory safety, forcing more explicit design (e.g. no function overload). Whether this is true or not is another discussion to have. In my experience, it helps to have stronger type system regardless of any language of comparison if you want to avoid logic errors.
    - kazinator 2y ago
      Not just logic errors but their problems in life, or something.
stouset 2y ago
> Safe Rust looks absolutely painful painful compared to other safe languages. It really isn't. It's quite nice to use. The big hangup is that Rust "wants" you to structure your programs according to a certain philosophy. Unfortunately the compiler can't teach you that approach directly, but can only complain when you write programs that don't abide by it. In my experience, following this design philosophy benefits even outside of memory safety, and I now write code following these principles in every language. > Correct C is not actually hard to write. Quite literally all of the available evidence strongly disagrees with this conclusion. > Correctness is more than just memory safety and avoiding overflows. They are still bugs in programs and languages that avoid those problems. This is true, but C lack tools to help with any of them. Fixing memory safety and overflows is in and of itself an enormous win, but Rust also has other tools that assist in program correctness (sum types being a huge one).
- kazinator 2y ago
  > Quite literally all of the available evidence strongly disagrees with this conclusion. Easy to write is not the same thing as easy to prove. It may be hard to show that some C program is correct, but when that is done, that doesn't change that it was easy to write (if that had been the case). C is actually "unreasonably effective". You can't just look at the problems; the overall picture is that a lot of large and complicated, yet well-working systems have been achieved in C. They may not be correct, but are "correct enough".
  - stouset 2y ago
    The number of large C programs which have been repeatedly proven to be incorrect in practice is essentially 100%. Still, C is unreasonably effective. A lot of large and complicated, yet mostly well-working (modulo regular CVEs) systems have been achieved in C. And that’s truly wonderful. I cut my teeth on C nearly 30 years ago and I still hold a soft spot in my heart for it. But other languages these days are even more unreasonably effective. They need fewer lines of code to achieve the same results and they have fewer security vulnerabilities and logic bugs per line as well.
rowanG077 2y ago
> Correct C is not actually hard to write. I would advise to you not say such blatantly false things. You paint yourself either as a liar or as unqualified. C has been proven time and time again to be almost impossible to write correctly. Even top tier programmers like djb cannot write safe C.
- kazinator 2y ago
  Nobody can write "safe C" because C is inherently not safe. See my other comment about it. Safe means something like "if the program breaks some semantic rule, it will be caught and diagnosed". It's not a statement about the program being correct or not, but the consequences of if it were to be incorrect. Even tiny, trivial programs have the potential to be incorrect without diagnosis. > C has been proven time and time again to be almost impossible to write correctly. Silly hyperbole.
  - rowanG077 2y ago
    Without writing safe C you cannot write correct C. If your C is unsafe it is incorrect by definition.
    - deleted 2y ago
      [deleted]
    - kazinator 2y ago
      That is obviously untrue by the definition of unsafe that I've been explicitly using. I've been sticking with the concept of unsafe language, whereas you're talking about an unsafe program. The two are related. An unsafe program misbehaves when given bad inputs. It's behavior is undefined. An unsafe language is an unsafe program with regard to bad inputs, which consist of certain kinds of incorrect programs. (Those which are not diagnosed). It's easy to write unsafe programs in unsafe languages. If we only focus on the program's functional requirements and none of them speak about what to do with bad inputs or in bad situations, we can end up with a program which is perfectly correct but unsafe. It will behave as specified on the correct inputs. If you happen to be advocating Rust due to misunderstanding this kind of material, you're in it for the wrong reasons.
signa11 2y ago
yup, after some experience, memory safety becomes kinda easy to get right. integer safety on the other hand is pretty hard, and non-trivial to get right unfortunately.
f1shy 2y ago
There are two big commandments of the modern programming religion: - Type safety - "Memory safety" We have to understand it: it is religion. No science. in 10 years maybe somebody start realising, that even with the 2 sw can still be very bad. And those 2 are not silver bullets... until then... patience.

WalterBright 2y ago

> On the other hand safe rust is so much easier than correct C that I don't particularly mind the tradeoff. D isn't Rust, but my personal style has gravitated towards the borrow checker rules anyway. It wouldn't be hard at all to do it in C, either. C's biggest security failing, however, is the lack of array bounds checking. It's always the #1 cause of security bugs in the field, by a wide margin. None of the workarounds in Standard C are attractive. I do not understand why the C committee adds all these bits and pieces of new features, and does not fix that problem. It's not like it's hard: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html The solution has been out there for 15 years now.

Gibbon1 2y ago
The standards people won't even add a standard buffer or slice to the language. I kinda cry every time I see a new api with foo(void *src, int sz) signatures.
- rurban 2y ago
  The standard people won't even add proper string support, besides their weak support for null-terminated buffers. Unicode strings have very special rules for searching, comparison and upper/lowercasing. And they are usually UTF-8 encoded.

justincredible 2y ago

[dead]