2 ms·

They are FOSS, but they are for a business, so yes, I will be affected. Rust is unfortunately not a reasonable alternative in some cases. As an example, my so

They are FOSS, but they are for a business, so yes, I will be affected. Rust is unfortunately not a reasonable alternative in some cases. As an example, my software needs just a C compiler to build itself. You can build my software completely with: tcc -run bootstrap/boostrap.c tcc This is because my software includes a build system meant to bootstrap other software. This use case is a good reason to avoid Rust. Another reason Rust may not be reasonable is the pervasiveness of async. Personally (not in general), async does not work for me. Rust is not the last word in programming languages. I am working on an alternative that will not only not have async, but will have more static analysis because destructors will be guaranteed to run. If you had read my post, you would know that I am planning to rewrite my stuff in that language as soon as possible. If Rust becomes required, I would be forced to stop work on that language, and progress would slow down. There are valid reasons to use C, even for software that handles untrusted inputs.

mustache_kimono 3y ago
> Rust is unfortunately not a reasonable alternative in some cases. Sure, and tort law is a flexible framework, so you will be allowed to make that argument. The only problem is if your software blows up in a way Rust was meant to prevent.
- gavinhoward 3y ago
  If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. I am trying to hit the same level of robustness as those, and if their level is still not acceptable, our industry will implode. I get that it's not okay to have 70% of vulnerabilities be memory safety bugs, but C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less.
  - mustache_kimono 3y ago
    > If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. 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"? My point was simply -- if your software is not in a place where damages occur, fine, who cares, write it in C. But if it is, and Rust exists, and could work just as well in that environment? And if you must still write in C, that's still fine, until you start selling software and causing your customers damages. > But C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less. Why?
    - gavinhoward 3y ago
      > 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.

mustache_kimono 3y ago

> Rust is unfortunately not a reasonable alternative in some cases. Sure, and tort law is a flexible framework, so you will be allowed to make that argument. The only problem is if your software blows up in a way Rust was meant to prevent.

gavinhoward 3y ago
If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. I am trying to hit the same level of robustness as those, and if their level is still not acceptable, our industry will implode. I get that it's not okay to have 70% of vulnerabilities be memory safety bugs, but C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less.
- mustache_kimono 3y ago
  > If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. 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"? My point was simply -- if your software is not in a place where damages occur, fine, who cares, write it in C. But if it is, and Rust exists, and could work just as well in that environment? And if you must still write in C, that's still fine, until you start selling software and causing your customers damages. > But C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less. Why?
  - gavinhoward 3y ago
    > 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.