In your opinion. Some of us believe the exact opposite.

By exact opposite you mean that when Java just came out ('I got an early look at Java, [...]') had good concurrency support?

One can make a solid argument that modern Java is adequate. But I don't buy you believe that of early Java?

There are a lot of good things about java (and the jvm by some extend), but good concurency is not one of them.

This is not true. JSR-133 was one of the first and most prominent implementation of memory model among general purpose languages. You don't seem to know enough about the platform and it's history to make definite statements like that, imo.

JSR-133 was quite a few years after Java's release. But even after these changes, many problems remained. For example, standard library classes were often not thread safe out-of-the-box, even something seemingly innocuous like a date formatter class would malfunction in a threaded context. The rules around thread safety were also very complex, especially with regard to constructing objects. IMHO, it did not compare well with other languages around the time built with concurrency in mind, for example Erlang. I was once very fortunate to meet Joe Armstrong and we briefly discussed Java, suffice to say he was not impressed by it.

+1

Old mate isn't alone.

I agree that Rust handles concurrency about as well as Java (in addition to its memory safety). But could you provide docs on Erlang or Haskell concurrent data structures that were better than Java’s, say, 10-20 years ago? Java’s support for concurrent data structures was pretty unprecedented in its heyday.

STM, 2006? https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67...

Still way after Java was released I guess

Java didn't initially ship with lock-free data structures, those came later thanks to Doug Lea.

The best example of this is probably the “Beautiful Concurrency” paper from Simon Peyton-Jones in 2007 https://www.microsoft.com/en-us/research/wp-content/uploads/...

Compared to those other languages, Java has no mechanism to enfore the use of concurrent data structures, it's entirely up to the programmer to use them.

Java still doesn't provide persistent data structures out-of-the-box. IMHO these are more important than lock-free mutable data structures.

When one really does need shared mutable state. Haskell supports transactional updates to mutable state (STM), with optimistic locking and rollbacks. It's awesome, but unfortunately just not practically possible in any language with rampant uncontrolled side-effects.

Erlang processes are a first class object. Data is immutable. There's a special syntax for sending and receiving messages between processes.

I would say that in some ways this is simply incomparable to java but I think this concurrency model is probably the easiest and simplest to work with of any concurrency model.

There are obviously drawbacks like with anything but for a lot of situations it's an excellent choice.

* * *