Freedom from data races is not hard and has nothing to do with managing lifetimes or avoiding GC; Concurrent Pascal did it in the 1970s for a language without shared references, Eiffel did it in the 1980s for references, too (and with GC). Rust just uses one specific model (the ownership approach, see in particular Boyapati's and Flanagan's papers), but it's not the only one. There's a huge body of research especially from the 1990s that covers this area in considerable detail.

The problem is that a lot of mainstream programming languages pretty much ignored the state of the art when implementing their concurrency models. See Per Brinch Hansen's rant about Java [1], for example.

[1] http://brinch-hansen.net/papers/1999b.pdf

I didn't say it was the only model, nor did I say that Rust was the origin of its style of data race prevention. You seem to be annoyed that Rust is using techniques similar to older research to avoid data races and also annoyed that other languages are ignoring the same older research??

Thank you for the references (although I think you meant Flanagan without an h). From a quick glance at one of the papers (without any guidance from an expert I have no idea where to start for a good summary), it seems like the retrofitted PRFJ has to fight the pervasive sharing of having a GC, resulting in a much less orthogonal system with higher annotation burden. In any case, at least two of the Rust team did PhDs in the areas of parallelism/concurrency so I'm sure they can give a more academic comparison of Rust and the research.

> You seem to be annoyed that Rust is using techniques similar to older research to avoid data races and also annoyed that other languages are ignoring the same older research??

Neither. I am just unhappy that these days avoidance from data races often gets reduced to the ownership approach and I wanted to provide a more complete picture (even if a quick summary is still woefully incomplete).

(And thanks for pointing out the typo – now fixed.)

> Additionally, lifetimes are also part of the system

That "additionally" is exactly why I said "more generally". I didn't say that lifetimes were not for thread safety. I just said that they were more generally for memory safety (I would count iterator invalidation etc as memory safety, would you not?).

Iterator invalidation can lead to memory unsafety in C++, usually due to a pointer or reference becoming dangling, but most other languages just treat it as a correctness problem: GC avoids the problem of invalidating pointers. As my parent comment hinted, some languages, like Java, try to detect (some occurrences of) these problems at runtime.

Some languages throw exceptions if their iterators are invalidated, right? That seems separate from memory safety to me.

Or put another way, having memory safety doesn't guarantee iterator safety.