3 ms·

I think this is a really good idea, and zig shows how it could work. But this? > Under these conditions it'd be easy to imagine most C programs running with f

I think this is a really good idea, and zig shows how it could work. But this? > Under these conditions it'd be easy to imagine most C programs running with fewer bugs (, leaks, etc.) than Rust programs. This is a crazy goal. You will never out-rust rust by adding a few runtime checks to C, while in debug mode. Fewer bugs than rust code is a wild goal. I don’t think you understand just how much rust’s design prevents you from shipping bugs. It’s due to a combination of so, so many things. Like: references instead of pointers, unsafe blocks, sum types & match instead of unions, no implicit nullability, unwrapping optional values is explicit, the result type and #[must_use], bounds checks, the borrow checker preventing use after free, ownership semantics, Send & Sync for thread safety, and I’m sure plenty more. It’s common to write very complex, threaded rust code and have it work first time. Well, the first time it compiles. Coming from C, it’s wild. Or, really, just about any other language. To get the same result in C wouldn’t just need a “strict mode”. You would need to ban raw pointers - which would make it no longer C. And you’d need to make functions return more than an (easily ignored) status code. Ie, you want a result type. For bounds checking, you’d need a language level data structure for slices / arrays (pointer + length). You’d have to do away with void pointers for “generic” parameters. And probably 100 other tiny, breaking changes that the C community will never accept. And for all that, you would essentially get zig. Zig does all these things. But that would still get you worse bug density than rust because you don’t have a borrow checker. It’ll get you close - Runtime checks in debug mode will detect your use after frees - if you have a good test suite. But they won’t prevent aliasing. Or (I think) help with thread safety. For that, you need a borrow checker. You need rust.

mjburgess 2y ago
We're talking about different kinds of bugs. One claim i'm making here is the poor iteration time imposed by Rust's complexity, significant design constraints, and so on, themselves cause kinds of bugs which are more readily addressed in C. Eg., I think memory leaks are easier in std Rust than in the kind of C i'm talking about. I don't think we have a good evidential basis for comparing the total class of programming bugs in Rust vs. comparable langs -- since there isn't that much Rust code. One "empirically ambitious" claim here is that the very high complexity of rust isn't design-bug-free, and "getting to 95%" with a modern C toolchain retains a very low-complexity get-it-done-and-iterate style of programming which has many "bug free'ing" advantages. Esp. if supported by a "debugger-oriented std lib"
- burntsushi 2y ago
  > "getting to 95%" with a modern C toolchain retains a very low-complexity get-it-done-and-iterate style of programming which has many "bug free'ing" advantages. Esp. if supported by a "debugger-oriented std lib" Speaking of things that don't have "good evidential basis"... I love how you apply an incredibly high standard of scrutiny to claims made by others but you neglect to do the same for your own claims. The idea that memory leaks in Rust are easier than in C, even in this C with this fantasy standard library, is just absolutely ludicrous. We are living in two different planes of existence. The C you're talking about doesn't exist and you're way way way over-stating the prevalence of bugs in Rust because of its iteration times/complexity/"design constraints." Which is another claim that doesn't have "good evidential basis." It's funny how the claims suggesting that Rust reduces bugs require a high standard of evidence, but the claims suggesting that Rust introduces new bugs that are more easily addressed by C are passed on without any scrutiny at all. And where did you get this 95% figure from? Did you just pull out of thin air? Where is your "good evidential basis"? Look, it's fine to theorize about things and have opinions and guesses. I get that. But when you don't let others have that same grace, your inconsistent application of evidentiary standards becomes plain.
  - mjburgess 2y ago
    The version of C i'm talking about does exist -- its a common practice of contemporary large-scale C development, which largely neglects libc and runs everything in debuggers/memory-tooling with strict options. You have also identified, as I have in my own comments, that some of my claims are as empirically difficult to verify.
    - burntsushi 2y ago
      This is what you said: > 95% of the supposed issues with C could be solved by a new standard library But now you're saying this does actually exist, and the answer is actually "no standard library" and not a "new standard library." Is this the same code responsible for all the memory safety CVEs we see? And great job at plucking one pittance out of my comment and responding to it, while completely ignoring the more substantive critique of your inconsistent application of evidentiary standards in your commentary. > You have also identified, as I have in my own comments, that some of my claims are as empirically difficult to verify. The circumspection you describe here does not at all come across in your commentary. Your commentary does not read like it has appropriate circumspection. Instead, you just state things as if they are facts: > 95% of the supposed issues with C could be solved by a new standard library, integrating the debugger into the compiler as the default build/run environment (with auto address sanitisation, frame protection, etc. etc.), and a default strict mode error checking. There is no circumspection there. There is no expression of uncertainty. There is no admission that you lack "good evidential basis." There's no concrete examples from you. No specific pointers to anything. Just made up statistics.

mjburgess 2y ago

We're talking about different kinds of bugs. One claim i'm making here is the poor iteration time imposed by Rust's complexity, significant design constraints, and so on, themselves cause kinds of bugs which are more readily addressed in C. Eg., I think memory leaks are easier in std Rust than in the kind of C i'm talking about. I don't think we have a good evidential basis for comparing the total class of programming bugs in Rust vs. comparable langs -- since there isn't that much Rust code. One "empirically ambitious" claim here is that the very high complexity of rust isn't design-bug-free, and "getting to 95%" with a modern C toolchain retains a very low-complexity get-it-done-and-iterate style of programming which has many "bug free'ing" advantages. Esp. if supported by a "debugger-oriented std lib"

burntsushi 2y ago
> "getting to 95%" with a modern C toolchain retains a very low-complexity get-it-done-and-iterate style of programming which has many "bug free'ing" advantages. Esp. if supported by a "debugger-oriented std lib" Speaking of things that don't have "good evidential basis"... I love how you apply an incredibly high standard of scrutiny to claims made by others but you neglect to do the same for your own claims. The idea that memory leaks in Rust are easier than in C, even in this C with this fantasy standard library, is just absolutely ludicrous. We are living in two different planes of existence. The C you're talking about doesn't exist and you're way way way over-stating the prevalence of bugs in Rust because of its iteration times/complexity/"design constraints." Which is another claim that doesn't have "good evidential basis." It's funny how the claims suggesting that Rust reduces bugs require a high standard of evidence, but the claims suggesting that Rust introduces new bugs that are more easily addressed by C are passed on without any scrutiny at all. And where did you get this 95% figure from? Did you just pull out of thin air? Where is your "good evidential basis"? Look, it's fine to theorize about things and have opinions and guesses. I get that. But when you don't let others have that same grace, your inconsistent application of evidentiary standards becomes plain.
- mjburgess 2y ago
  The version of C i'm talking about does exist -- its a common practice of contemporary large-scale C development, which largely neglects libc and runs everything in debuggers/memory-tooling with strict options. You have also identified, as I have in my own comments, that some of my claims are as empirically difficult to verify.
  - burntsushi 2y ago
    This is what you said: > 95% of the supposed issues with C could be solved by a new standard library But now you're saying this does actually exist, and the answer is actually "no standard library" and not a "new standard library." Is this the same code responsible for all the memory safety CVEs we see? And great job at plucking one pittance out of my comment and responding to it, while completely ignoring the more substantive critique of your inconsistent application of evidentiary standards in your commentary. > You have also identified, as I have in my own comments, that some of my claims are as empirically difficult to verify. The circumspection you describe here does not at all come across in your commentary. Your commentary does not read like it has appropriate circumspection. Instead, you just state things as if they are facts: > 95% of the supposed issues with C could be solved by a new standard library, integrating the debugger into the compiler as the default build/run environment (with auto address sanitisation, frame protection, etc. etc.), and a default strict mode error checking. There is no circumspection there. There is no expression of uncertainty. There is no admission that you lack "good evidential basis." There's no concrete examples from you. No specific pointers to anything. Just made up statistics.