I think you've highlighted the answer there - that working with shared memory is easy to mess up and that immutability and message passing both provide some attractive aspects. The thing is, not every problem is solvable (and to a much larger extent, optimizable) without some concept of concurrency and all of the problems of mutual access that come along with it. I don't think the mutual exclusion problem is typically that bad with modern java - profilers let you visualize your locking issues, atomic variables let you squeeze cycles and really the correctness problem is not that hard, it's the performance optimization problem. I would rather my problems be explicit and in front of my face than hidden in some detail about event loops, method invocation time impacting other method invocations and so forth. The other important point is that as soon as you get into working in a clustered environment, you start having to think about distributed locks and concurrency when there is not even a shared clock to rationalize things. So, for product oriented engineers, great go use nodejs and you can write JS on the front end and the back end and it will be absolutely tremendous guys, I am telling you :) If we want to talk about judging languages on technical features (as this article starts the ball rolling on) then we can't just bandaid real problems with easily approachable solutions and write off any actual complexity as out of scope.

> I don't think the mutual exclusion problem is typically that bad with modern java - profilers let you visualize your locking issues, atomic variables let you squeeze cycles and really the correctness problem is not that hard, it's the performance optimization problem.

This only allows you to strangle yourself in a more CPU-efficient manner.

Locks et al. are low level interface, too low level for a language that pretends to be a high level one (like Java does).

> The other important point is that as soon as you get into working in a clustered environment, you start having to think about distributed locks and concurrency when there is not even a shared clock to rationalize things.

Once you go into clusters, you loose your precious notion of shared memory anyway (unless the distributed shared memory is still a thing; I haven't checked lately, but I thought it was an abandoned paradigm).

> So, for product oriented engineers, great go use nodejs and you can write JS on the front end and the back end and it will be absolutely tremendous

I don't know why are you implying that I either work on frontend, with web applications, or Node.js. I do none of these.

>This only allows you to strangle yourself in a more CPU-efficient manner.

I thought you meant losing cycles due to blocking or spinlocks when you said strangling.

>Locks et al. are low level interface

Actually no, this is the world of multiple cores. Threads are the most trivially accessible way to parallelize activities, so they are just a modern primitive.

>Once you go into clusters, you loose your precious notion of shared memory anyway

Zookeeper. Distributed clocks and sequences and all that often require a few bits.

I was just making fun in the last sentence, if you didn't catch the linguistic joke about populism in my word choice. I'd guess you work in erlang.

> Parallelism using message passing.

So... both immutable data structure (messages) and an event loop (message queue/reader).