[keefe]

I tend to agree with your points here - if you end up in a conversation with that guy, I would also add:

1 Java does get concurrency right and the trade-off made in going to a single threaded nodejs process will appear (as I have bitterly learned) as performance becomes important. Keeping a sanitary event loop (think about large uploads, downloads) turns out to also be a difficult problem and one with less tooling and experience.

2. Allocate Direct can be used to get off heap memory, I don't recommend doing this, but if you really need to worry about your GC pauses, then it is very possible to use java without it and I have seen that done.

[dozzie]

> 1 Java does get concurrency right

Strangling yourself with mutexes on shared memory is not "concurrency done right".

[keefe]

no that's concurrency done right, used wrong. What do you want, immutable structures or event loop?

[dozzie]

Parallelism using message passing. Writing with shared memory is so easy to mess up. Been in both worlds, one is sensible, the other is atrocious.

[keefe]

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.

[dozzie]

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

[keefe]

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

[jdbernard]

> Parallelism using message passing.

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