4 ms·

I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the s

by crawshaw 10mo ago

I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace https://research.swtch.com/gorace, it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort of thing I have seen again and again in the Rust "community" that I find deeply off-putting. Build good things, do not play snooty word games.

saagarjha 10mo ago
Why do you think data races are not a practical source of bugs?
- crawshaw 10mo ago
  Data races are a source of bugs. They are not a noticeable fraction of the security issues that face memory unsafe languages, which is the practical argument for memory safety.
  - saagarjha 10mo ago
    No they’re pretty important these days now that basic linear overflows and the like are harder to exploit
    - tptacek 10mo ago
      OK, show us all the data race code execution CVEs in Go code.
      - saagarjha 10mo ago
        I was discussing data races in the scope of all memory unsafe languages, I don't really know enough about Go to know whether people are looking for these.
- pjmlp 10mo ago
  They are, pity that Rust type system has nothing to prevent them outside a very specific use case of in-memory data structures and threads. Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment. Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.
  - saagarjha 10mo ago
    If you have both sides cooperating, then it's perfectly reasonable to write a safe interface on top of shared memory. If not…well, what do you suggest? Also, pointing at the overwhelming majority of code and going "this is a very specific use case" is also kind of wild, because even in IPC scenarios there will be in-memory data that needs protection.
    - pjmlp 10mo ago
      What I suggest is getting the marketing message correctly.
      - saagarjha 10mo ago
        What should it be?
  - SkiFire13 10mo ago
    Are you perhaps confusing data races with race conditions?
    - pjmlp 10mo ago
      Nope, because it depends on how memory storage is mapped on the process, linker scripts and other fun tricks in systems programming, outside Rust's type system.
deleted 10mo ago
[deleted]
AnthonyMouse 10mo ago
The thing that annoys me more is the singular focus on memory safety as if nothing else matters. For example, by most definitions PHP is a "memory safe" language, but it's also full of poor design choices and the things written in it have a disproportionate number of security vulnerabilities. JavaScript is also classically modeled as a gelatinous mass of smoldering tires and npm seems to have been designed for the purpose of carrying out supply chain attacks. So then we see an enormous amount of effort being spent to try to replace everything written in C with Rust when that level of effort should have been able to e.g. come up with something which is easy enough for ordinary people to use that it could plausibly displace WordPress but has a better security posture. Or improve the various legacy issues with distribution package managers so that people stop avoiding them even for popular packages in favor of perilous kludges like npm and Docker.
- aw1621107 10mo ago
  > JavaScript is also classically modeled as a gelatinous mass of smoldering tires TypeScript exists? So I'm not too sure that everyone is focusing entirely on memory safety... > So then we see an enormous amount of effort being spent to try to replace everything written in C with Rust when that level of effort should have been able to e.g. come up with something which is easy enough for ordinary people to use that it could plausibly displace WordPress but has a better security posture. I feel like this is somewhat... inconsistent? At the risk of oversimplifying a bit (or more), Rust is "something which is easy enough for ordinary people to use that it could plausibly displace [C/C++] but has a better security posture" (not saying that it's the only option, of course). So now that all that effort has been expended in producing Rust, you want to just... forgo applying the solution and redirect that effort to working on solutions to other problems? What happens when you come up with solutions to those? Drop those solutions on the floor as well in favor of solving yet other issues? I think another explanation for allocation of effort here is due to the difference between creating a solution and applying a solution. At the risk of oversimplifying yet again, "replace C with Rust" is applying a known solution with known benefits/drawbacks to a known problem. Can you say the same about "[i]mprov[ing] the various legacy issues with distribution package managers so that people stop avoiding them even for popular packages in favor of perilous kludges like npm and Docker", let alone coming up with an easy-to-use more secure WordPress replacement?
testdelacc1 10mo ago
While we’re on the subject of what’s deeply off-putting - how did you generalise to a “community” based on one persons comment. When did Codys become representative of such a large group? By the same token can I say your comment here is representative of all HN comments?
jojomodding 10mo ago
> it is not an inherent feature of the language, just the implementation So what is it now? If the implementation is correct in allowing you to cause UB with data races, then this is very much a feature of the language, making the language not memory-safe. Alternatively, the implementation is buggy here, in which case there should be a bug report somewhere. Is there such a bug report (github issue)? Is there a line in the spec saying this is the intended behavior?

saagarjha 10mo ago

Why do you think data races are not a practical source of bugs?

crawshaw 10mo ago
Data races are a source of bugs. They are not a noticeable fraction of the security issues that face memory unsafe languages, which is the practical argument for memory safety.
- saagarjha 10mo ago
  No they’re pretty important these days now that basic linear overflows and the like are harder to exploit
  - tptacek 10mo ago
    OK, show us all the data race code execution CVEs in Go code.
    - saagarjha 10mo ago
      I was discussing data races in the scope of all memory unsafe languages, I don't really know enough about Go to know whether people are looking for these.
pjmlp 10mo ago
They are, pity that Rust type system has nothing to prevent them outside a very specific use case of in-memory data structures and threads. Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment. Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.
- saagarjha 10mo ago
  If you have both sides cooperating, then it's perfectly reasonable to write a safe interface on top of shared memory. If not…well, what do you suggest? Also, pointing at the overwhelming majority of code and going "this is a very specific use case" is also kind of wild, because even in IPC scenarios there will be in-memory data that needs protection.
  - pjmlp 10mo ago
    What I suggest is getting the marketing message correctly.
    - saagarjha 10mo ago
      What should it be?
- SkiFire13 10mo ago
  Are you perhaps confusing data races with race conditions?
  - pjmlp 10mo ago
    Nope, because it depends on how memory storage is mapped on the process, linker scripts and other fun tricks in systems programming, outside Rust's type system.

deleted 10mo ago

[deleted]

AnthonyMouse 10mo ago

The thing that annoys me more is the singular focus on memory safety as if nothing else matters. For example, by most definitions PHP is a "memory safe" language, but it's also full of poor design choices and the things written in it have a disproportionate number of security vulnerabilities. JavaScript is also classically modeled as a gelatinous mass of smoldering tires and npm seems to have been designed for the purpose of carrying out supply chain attacks. So then we see an enormous amount of effort being spent to try to replace everything written in C with Rust when that level of effort should have been able to e.g. come up with something which is easy enough for ordinary people to use that it could plausibly displace WordPress but has a better security posture. Or improve the various legacy issues with distribution package managers so that people stop avoiding them even for popular packages in favor of perilous kludges like npm and Docker.

aw1621107 10mo ago
> JavaScript is also classically modeled as a gelatinous mass of smoldering tires TypeScript exists? So I'm not too sure that everyone is focusing entirely on memory safety... > So then we see an enormous amount of effort being spent to try to replace everything written in C with Rust when that level of effort should have been able to e.g. come up with something which is easy enough for ordinary people to use that it could plausibly displace WordPress but has a better security posture. I feel like this is somewhat... inconsistent? At the risk of oversimplifying a bit (or more), Rust is "something which is easy enough for ordinary people to use that it could plausibly displace [C/C++] but has a better security posture" (not saying that it's the only option, of course). So now that all that effort has been expended in producing Rust, you want to just... forgo applying the solution and redirect that effort to working on solutions to other problems? What happens when you come up with solutions to those? Drop those solutions on the floor as well in favor of solving yet other issues? I think another explanation for allocation of effort here is due to the difference between creating a solution and applying a solution. At the risk of oversimplifying yet again, "replace C with Rust" is applying a known solution with known benefits/drawbacks to a known problem. Can you say the same about "[i]mprov[ing] the various legacy issues with distribution package managers so that people stop avoiding them even for popular packages in favor of perilous kludges like npm and Docker", let alone coming up with an easy-to-use more secure WordPress replacement?

testdelacc1 10mo ago

While we’re on the subject of what’s deeply off-putting - how did you generalise to a “community” based on one persons comment. When did Codys become representative of such a large group? By the same token can I say your comment here is representative of all HN comments?

jojomodding 10mo ago

> it is not an inherent feature of the language, just the implementation So what is it now? If the implementation is correct in allowing you to cause UB with data races, then this is very much a feature of the language, making the language not memory-safe. Alternatively, the implementation is buggy here, in which case there should be a bug report somewhere. Is there such a bug report (github issue)? Is there a line in the spec saying this is the intended behavior?