3 ms·

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,

• 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
        It's not a critique if I myself point it out in my own comments -- there isnt anything to reply to. HN comment threads are not the place for empirical research; but I can nevertheless point to its absence in official sales pitches. Yes, people write their own stdlib for C, and the better ones are written effectively "for the debugger". This is code that runs spaceships, nuclear power plants, xray machines, and the like. Rust fanatics exist in this parallel universe in which it was, necessarily, the language which was the original sin -- so that Rust can be sold upon a cross as the redemption for C. There's plenty of existence-proof systems that are written in C with the goal of saftey and reliability. No libc, and historical programming in general did not have that goal. This has vastly more to do with the history of programming, and its assumptions of non-adversarial low-risk host systems -- than to do with what contemporary C development necessarily looks like. As-if C developers are actually unable to detect use-after-free or double-free etc. std memory saftey issues; it's absurd.
• josephg 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. Huh? Memory leaks? Poor iteration time? "Different kinds of bugs"? What are you talking about? How do you leak memory in rust by accident? I've worked fulltime in rust for ~3-4 years and I don't think I've ever leaked memory in my code. I did it once on purpose in a script - but that was by explicitly calling Box.leak(). Poor iteration time? What? In my experience, iteration time in rust is significantly faster than that of C. Sure - the first program you write is hard, because learning rust is horrible. But once you know it, the ergonomics of the language make it a dream to work in. People make a big deal of the borrow checker, but its all the little things that the language does right that makes it productive to work in. Sum types. Match expressions. Iterators. Cargo. Editions. #[test]. References. Option and Result. Documentation. A standard library that works the same on every platform. And so on. Turns out we got better at inventing programming languages in the 50 years since C was invented. This isn't a rust thing - Swift, Zig and - in many ways - typescript and C# all support the same great feature set. If you want to complain about rust, get in line. I'm no fanboy, and there's a laundry list of legitimate complaints you can make about the language. I've written thousands of words on the subject and annoyed a lot of people right here on HN in the process. But you have to use it if you want to understand its flaws. It sounds like you're just inventing problems with rust from nowhere. How dull.