> 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.

▲

ralfj 4 days ago | parent | next [-]

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 4 days ago | parent [-]

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 3 days ago \| parent [-]
		> 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-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.

▲

dwattttt 5 days ago | parent | prev [-]

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'.

▲

pizlonator 5 days ago | parent | next [-]

> 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 5 days ago | parent [-]

> 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

▲

pizlonator 5 days ago | parent [-]

> By these definitions, doesn't that mean go is neither memory or thread safe?

Yes, with the caveat that you can't treat "memory safe" as a binary condition.

The strictest notion of memory safety is what I call GIMSO: "Garbage In, Memory Safety Out". I.e. there does not exist any sequence of bytes you could feed to the compiler that would result in a memory-unsafe outcome at runtime. Java aims for this. Fil-C does too. JavaScript also does.

But there are languages that I think it's fair to consider to be memory safe that offer escape hatches that violate GIMSO. Rust with `unsafe` is an example. C# with `unsafe` is another. Java if you include `sun.misc.Unsafe` (arguably it's not part of the language).

So I think if a language is memory safe, not thread safe, and the memory safety is gated on thread safety, then it's kinda fair to make statements like, "it's memory safe", if you have fine print somewhere that says "but the memory safety does not hold under the following kinds of races".

All of that said, I'd rather we just said that "memory safety" means what I call "GIMSO". But the ship has sailed. Lots of languages are called "memory safe" to mean something like, "you can get memory safety in this language if you obey certain idioms" - and in Rust that means "don't use unsafe" while in Go that means "don't race in certain ways".

▲

SkiFire13 4 days ago | parent [-]

In my opinion this is missing a very important different between the two approaches: using `unsafe`/`sun.misc.Unsafe` in Rust/C#/Java is a very deliberate choice which presence can easily be checked syntactically, meanwhile data races in Go are most often unintended and you can't easily check for their _guaranteed_ absence. Otherwise C/C++ are also "GIMSO" with the caveat "don't UB"!

	▲	pizlonator 4 days ago \| parent [-]
		GIMSO is defined as memory safety without caveats. The only way to get it (currently) in C/C++ is to compile with Fil-C. You have a good point otherwise, but Go is considered memory safe anyway. And it probably makes sense that it is, since the chances of exploitation due to memory safety issues caused by races in Go are infinitesimal. It’s not at all fair to compare to the exploited-all-the-time issues of C/C++ (when you make the mistake of compiling with something other than Fil-C)

▲

dwattttt 5 days ago | parent | prev [-]

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 5 days ago \| parent [-]
		Yeah and Rust is guaranteed to be thread safe unless 'unsafe' is involved, I think