6 ms·

I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: > At

I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: > At this point you might be wondering, isn’t this a problem in many languages? Doesn’t Java also allow data races? And yes, Java does allow data races, but the Java developers spent a lot of effort to ensure that even programs with data races remain entirely well-defined. They even developed the first industrially deployed concurrency memory model for this purpose, many years before the C++11 memory model. The result of all of this work is that in a concurrent Java program, you might see unexpected outdated values for certain variables, such as a null pointer where you expected the reference to be properly initialized, but you will never be able to actually break the language and dereference an invalid dangling pointer and segfault at address 0x2a. In that sense, all Java programs are thread-safe. And: > Java programmers will sometimes use the terms “thread safe” and “memory safe” differently than C++ or Rust programmers would. From a Rust perspective, Java programs are memory- and thread-safe by construction. Java programmers take that so much for granted that they use the same term to refer to stronger properties, such as not having “unintended” data races or not having null pointer exceptions. However, such bugs cannot cause segfaults from invalid pointer uses, so these kinds of issues are qualitatively very different from the memory safety violation in my Go example. For the purpose of this blog post, I am using the low-level Rust and C++ meaning of these terms. Java is in fact thread-safe in the sense of the term used in the article, unlike Go, so it is not a counterexample to the article's point at all.

pizlonator 1y ago
> I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: The title is wrong. That's important. > Java is in fact thread-safe in the sense of the term used in the article The article's notion of thread safety is wrong. Java is not thread safe by construction, but it is memory safe.
- dwattttt 1y ago
  If a language is "memory safe", by some definition we expect safety from memory faults (for example, not accessing memory incorrectly). If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"? Or to put it another way; when used however the term of art is intended, "memory safety" is meant to provide some guarantees about not triggering certain erroneous conditions. "not thread safe" seems to mean that those same erroneous conditions can be triggered by threads, which seems to amount to '"memory safety" does not guarantee the absence of erroneous memory conditions'.
  - dwattttt 1y ago
    I guess to also elaborate the point; it's also entirely correct to say "Rust is guaranteed to be memory safe unless 'unsafe' is involved".
    - pizlonator 1y ago
      Yeah and Rust is guaranteed to be thread safe unless 'unsafe' is involved, I think
  - pizlonator 1y ago
    > If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"? Yes. If a language is memory safe but not thread safe, then you can race, but the outcome of those races won't be memory corruption or the violation of the language's type system. It will lead to weird stuff, however - just a different kind of weirdness than breaking out of the language's sandbox
    - dwattttt 1y ago
      > If a language is memory safe but not thread safe, then you can race, but the outcome of those races won't be memory corruption or the violation of the language's type system. By these definitions, doesn't that mean go is neither memory or thread safe? It looks like concurrent modification can result in memory corruption, e.g. the attempted access 0x42 example in the article
- ralfj 1y ago
  Java also sometimes uses "memory safe" to refer to programs that don't have null pointer exceptions. So in that sense, Java isn't memory safe by construction either. These terms are used slightly differently by different communities, which is why I discuss this point in the article. But you seem adamant that you have the sole authority for defining these terms so :shrug:
  - pizlonator 1y ago
    When those US government articles about how we should switch to memory safe languages come out, they refer to Java as a “memory safe language”. They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages). So no, I’m not an authority. I’m just following the general trend of how the term is used. And ive never heard “memory safe” used in relation to not having null pointer exceptions. That’s a new one and sounds nonsensical, frankly
    - ralfj 1y ago
      > They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages). For Java, there's no contradiction if you define data race freedom as "data races cannot cause arbitrary memory corruption / UB". > And ive never heard “memory safe” used in relation to not having null pointer exceptions. That’s a new one and sounds nonsensical, frankly I was also surprised, but it's what I was told by people working on verification of Java programs. And you can see e.g. at https://link.springer.com/content/pdf/10.1007/978-3-030-17502-3_9.pdf https://link.springer.com/content/pdf/10.1007/978-3-030-1750... that people are proving memory safety of Java programs, which would not make sense at all if all Java programs are memory safe by construction.

pizlonator 1y ago

> I would recommend reading beyond the title of a post before leaving replies like this, as your comment is thoroughly addressed in the text of the article: The title is wrong. That's important. > Java is in fact thread-safe in the sense of the term used in the article The article's notion of thread safety is wrong. Java is not thread safe by construction, but it is memory safe.

dwattttt 1y ago
If a language is "memory safe", by some definition we expect safety from memory faults (for example, not accessing memory incorrectly). If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"? Or to put it another way; when used however the term of art is intended, "memory safety" is meant to provide some guarantees about not triggering certain erroneous conditions. "not thread safe" seems to mean that those same erroneous conditions can be triggered by threads, which seems to amount to '"memory safety" does not guarantee the absence of erroneous memory conditions'.
- dwattttt 1y ago
  I guess to also elaborate the point; it's also entirely correct to say "Rust is guaranteed to be memory safe unless 'unsafe' is involved".
  - pizlonator 1y ago
    Yeah and Rust is guaranteed to be thread safe unless 'unsafe' is involved, I think
- pizlonator 1y ago
  > If a language is "memory safe" but not "thread safe", is the result "the language is free from 'memory faults', unless threads are involved"? Yes. If a language is memory safe but not thread safe, then you can race, but the outcome of those races won't be memory corruption or the violation of the language's type system. It will lead to weird stuff, however - just a different kind of weirdness than breaking out of the language's sandbox
  - dwattttt 1y ago
    > If a language is memory safe but not thread safe, then you can race, but the outcome of those races won't be memory corruption or the violation of the language's type system. By these definitions, doesn't that mean go is neither memory or thread safe? It looks like concurrent modification can result in memory corruption, e.g. the attempted access 0x42 example in the article
ralfj 1y ago
Java also sometimes uses "memory safe" to refer to programs that don't have null pointer exceptions. So in that sense, Java isn't memory safe by construction either. These terms are used slightly differently by different communities, which is why I discuss this point in the article. But you seem adamant that you have the sole authority for defining these terms so :shrug:
- pizlonator 1y ago
  When those US government articles about how we should switch to memory safe languages come out, they refer to Java as a “memory safe language”. They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages). So no, I’m not an authority. I’m just following the general trend of how the term is used. And ive never heard “memory safe” used in relation to not having null pointer exceptions. That’s a new one and sounds nonsensical, frankly
  - ralfj 1y ago
    > They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages). For Java, there's no contradiction if you define data race freedom as "data races cannot cause arbitrary memory corruption / UB". > And ive never heard “memory safe” used in relation to not having null pointer exceptions. That’s a new one and sounds nonsensical, frankly I was also surprised, but it's what I was told by people working on verification of Java programs. And you can see e.g. at https://link.springer.com/content/pdf/10.1007/978-3-030-17502-3_9.pdf https://link.springer.com/content/pdf/10.1007/978-3-030-1750... that people are proving memory safety of Java programs, which would not make sense at all if all Java programs are memory safe by construction.