2 ms·

> If your software blows up, in a way Rust would have prevented, and caused damages, isn't it kind of fair someone say "Hey maybe you shouldn't be using C"? No

> If your software blows up, in a way Rust would have prevented, and caused damages, isn't it kind of fair someone say "Hey maybe you shouldn't be using C"? No, that would not automatically be fair. It depends on context. > But if it is, and Rust exists, and could work just as well in that environment? But that's what I am saying: Rust won't work as well in that environment. My stretch goal is to have my build system replace the awful custom Makefile build for FreeBSD. In that context, Rust doesn't exist, even if they add it to the base system because something would have to build Rust and LLVM. Same reason my bc is in C: it is used to build the Linux kernel. Anyway, who defines if Rust works "just as well" in an environment? It all depends on context. You can't say that any Tier 1 and Tier 2 platform must use Rust for reasons such as the one I laid out above. And what if my language succeeds and has more bug smashing power than Rust? Should the directive immediately be, "If any Rust project causes damages that Yao could have prevented, that project owner is liable"? Of course not. > > But C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less. > Why? Call it a hunch, but roughly, I think that a C project that reduces its memory bugs to that much would have fewer vulnerabilities than an equivalent Rust project, just because it would smash a lot of non-memory bugs along the way. That is the criteria that should be used: how many bugs does it have per KLoC, number of statements, cyclomatic complexity, whatever. Otherwise, you're just effectively mandating Rust anyway, and Rust projects could get away with murder. But set an objective criteria like that, and SQLite and Curl would survive, I would make my project hit it, and poorly done Rust projects would have to clean up their act. IOW, I do agree that Rust should be the default, but we shouldn't choose a metric that is clearly biased in its favor.

mustache_kimono 3y ago
> But that's what I am saying: Rust won't work as well in that environment. Well then the problem would be different?! If instead the problem is the problem as I described it, you have an issue! > Anyway, who defines if Rust works "just as well" in an environment? Dude, you're super angry about Rust and you are refusing to address how any of this might work in a products liability context. If you want to say software development is so inherently creative, and subjective, it can never have standards, standards which the rest of the world relies upon to build cars and toys and industrial boilers, then good luck with that opinion. > Call it a hunch, but roughly, I think that a C project that reduces its memory bugs to that much would have fewer vulnerabilities than an equivalent Rust project, just because it would smash a lot of non-memory bugs along the way. Good luck making this argument! > IOW, I do agree that Rust should be the default, but we shouldn't choose a metric that is clearly biased in its favor. Unfortunate for you, products liability is actually about that metric: safety. If you want to forgo better practices, languages, etc., that's fine. Because products liability law could never simply mandate Rust. You must only be reasonable in your decision making process.
- gavinhoward 3y ago
  > Well then the problem would be different?! If instead the problem is the problem as I described it, you have an issue! Maybe. Others will have different situations, so no, even if the problem is as you described it, you may have left out some variable that precludes Rust. > you are refusing to address how any of this might work in a products liability context. Yes, I did. I said that we need some objective measure, and I gave a few examples. Anything that doesn't measure up gets hit with liability. > If you want to say software development is so inherently creative, and subjective, it can never have standards, standards which the rest of the world relies upon to build cars and toys and industrial boilers, then good luck with that opinion. I never said we could not have standards. That is the opposite of what I said. I said that we should have a fair objective measure as a standard, not "no memory bugs" or "always write in Rust on Tier 1 and 2 platforms." > Good luck making this argument! It will actually be easier with time as more Rust projects appear. But as a taste, I find it illuminating that, despite calls to rewrite SQLite and Curl in Rust, no one making those calls has actually sat down to do it. And I do have some personal data in that regard. [1] > Unfortunate for you, products liability is actually about that metric: safety. If you want to forgo better practices, languages, etc., that's fine. Because products liability law could never simply mandate Rust. You must only be reasonable in your decision making process. Yes, I agree. But if we choose the wrong standard, then products liability law will effectively mandate Rust, and that would not be good. And "safety" is not just about memory safety; it's about that and everything else. Rust is not a valid excuse to forget everything else. [1]: https://gavinhoward.com/2023/12/am-i-a-good-c-programmer/ https://gavinhoward.com/2023/12/am-i-a-good-c-programmer/

mustache_kimono 3y ago

> But that's what I am saying: Rust won't work as well in that environment. Well then the problem would be different?! If instead the problem is the problem as I described it, you have an issue! > Anyway, who defines if Rust works "just as well" in an environment? Dude, you're super angry about Rust and you are refusing to address how any of this might work in a products liability context. If you want to say software development is so inherently creative, and subjective, it can never have standards, standards which the rest of the world relies upon to build cars and toys and industrial boilers, then good luck with that opinion. > Call it a hunch, but roughly, I think that a C project that reduces its memory bugs to that much would have fewer vulnerabilities than an equivalent Rust project, just because it would smash a lot of non-memory bugs along the way. Good luck making this argument! > IOW, I do agree that Rust should be the default, but we shouldn't choose a metric that is clearly biased in its favor. Unfortunate for you, products liability is actually about that metric: safety. If you want to forgo better practices, languages, etc., that's fine. Because products liability law could never simply mandate Rust. You must only be reasonable in your decision making process.

gavinhoward 3y ago
> Well then the problem would be different?! If instead the problem is the problem as I described it, you have an issue! Maybe. Others will have different situations, so no, even if the problem is as you described it, you may have left out some variable that precludes Rust. > you are refusing to address how any of this might work in a products liability context. Yes, I did. I said that we need some objective measure, and I gave a few examples. Anything that doesn't measure up gets hit with liability. > If you want to say software development is so inherently creative, and subjective, it can never have standards, standards which the rest of the world relies upon to build cars and toys and industrial boilers, then good luck with that opinion. I never said we could not have standards. That is the opposite of what I said. I said that we should have a fair objective measure as a standard, not "no memory bugs" or "always write in Rust on Tier 1 and 2 platforms." > Good luck making this argument! It will actually be easier with time as more Rust projects appear. But as a taste, I find it illuminating that, despite calls to rewrite SQLite and Curl in Rust, no one making those calls has actually sat down to do it. And I do have some personal data in that regard. [1] > Unfortunate for you, products liability is actually about that metric: safety. If you want to forgo better practices, languages, etc., that's fine. Because products liability law could never simply mandate Rust. You must only be reasonable in your decision making process. Yes, I agree. But if we choose the wrong standard, then products liability law will effectively mandate Rust, and that would not be good. And "safety" is not just about memory safety; it's about that and everything else. Rust is not a valid excuse to forget everything else. [1]: https://gavinhoward.com/2023/12/am-i-a-good-c-programmer/ https://gavinhoward.com/2023/12/am-i-a-good-c-programmer/