I think Java is accidentally on that list, because it's had excellent concurrency stories since it came out, got complicated when they removed "green threads", thereby pushing thread pool management into the programmer's set of responsibilities, but is reworking its former ergonomics with its project loom.
for the rest of the listed languages, definitely agree.
Hard disagree. The java concurrency story was absolutely awful when it came out. It had terrible ideas which panned out as well as checked exceptions did, and got forgotten when the collections were reworked. The only things it had going for it were showing concern and a well defined memory model, but that was broken until JSR 133.
Java concurrency got a lot better with JSR 166, by accreting new APIs. But those require awareness of their existence and purpose, the langage baseline is no better.
Project loom does not fundamentally change any of that. It’s goal is to increase efficiency, aka get more wrong answers faster.
What do you mean by "get more wrong answers faster"? Given that volatile / synchronized have largely gone the way of the dodo, ditto Object.wait etc.
, and that concurrency safe atomics and collections are de rigeur, how do green threads reverse that? (I understand your point that you need to use the good stuff to take advantage of it, and that the old bad stuff is still in the base language, but I feel that's true for pretty much every language that's 30ish years old.)
I spent years working on concurrent Java apps post JSR 166, and the only concurrency issues I met were PEBKAC, and some of the awful things people did with Vert.x and it's event bus.
Do you have a good resource or summary on why volatile / synchronized are problematic and java.util.concurrent should be preferred?
I always remembered the same, but was recently in a conversation with Java devs who contradicted it, and could not articulate well why this is the case. and could not find good resources on it.
Anyone can do "concurrency" by starting from scratch with a fresh process each time. That isn't "having a concurrency story" it's rather the opposite I think. It's very wasteful of system resources, energy, etc.
PHPs model would be okay if they used green threads/goroutines. That way, you can have a far larger number of workers, as most of them are blocked on database connections or HTTP requests to other services.
It has proved successful so far. The shared-nothing, short-lived process avoids classes of issues such as with slow memory leaks, accidentally blocking event loops, and shared memory threading issues.
Most PHP sites will utilise php-fpm, so it isn't really true that each request will spawn another PHP process.
The language historically hasn't been that great, but its shared-nothing architecture has always been the good part.
