3 ms·

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 a

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.
- burntsushi 2y ago
  Wait, you're whinging about Rust's iteration time and complexity, but in the same breath talking about code written for spaceships and nuclear power plants!?!? That's what you're comparing it too!? Do you have actual experience writing programs for spaceships and nuclear power plants? I don't, but I sure as hell would imagine that the regulatory requirements for it make it way more expensive to write than wrangling with rustc. Holy moly. > Rust fanatics Oh okay, so if we're going to go there, then I just get to call you a C fanatic. And yes, indeed, we live on two different planes of existence, as I said. That's for damn sure. > but I can nevertheless point to its absence in official sales pitches Which "official sales pitches"? I don't see any in this HN thread. Yet again applying inconsistent evidentiary standards. > 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. You might be saying something significant in that paragraph of word salad, but I can't spot it. I'm not confused as to why C is the way it is. That isn't the interesting bit. > As-if C developers are actually unable to detect use-after-free or double-free etc. std memory saftey issues; it's absurd. Odd that they keep making that mistake then!

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.

burntsushi 2y ago
Wait, you're whinging about Rust's iteration time and complexity, but in the same breath talking about code written for spaceships and nuclear power plants!?!? That's what you're comparing it too!? Do you have actual experience writing programs for spaceships and nuclear power plants? I don't, but I sure as hell would imagine that the regulatory requirements for it make it way more expensive to write than wrangling with rustc. Holy moly. > Rust fanatics Oh okay, so if we're going to go there, then I just get to call you a C fanatic. And yes, indeed, we live on two different planes of existence, as I said. That's for damn sure. > but I can nevertheless point to its absence in official sales pitches Which "official sales pitches"? I don't see any in this HN thread. Yet again applying inconsistent evidentiary standards. > 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. You might be saying something significant in that paragraph of word salad, but I can't spot it. I'm not confused as to why C is the way it is. That isn't the interesting bit. > As-if C developers are actually unable to detect use-after-free or double-free etc. std memory saftey issues; it's absurd. Odd that they keep making that mistake then!