Hacker News Reader

Comment by brlewis | Hacker News Reader

One big reason why running on the JVM was a success factor for Clojure was that in Java, concurrency is hard.

Concurrency is hard anyway, but in Java it's considerably easier than it could have been (I'm thinking C++) given you know that java.util.concurrent exists and have a handy reference to the relevant book. Even having 'synchronized' as a primitive keyword has its benefits... But Java wasn't born with java.util.concurrent, Clojure had the benefit of being able to follow (IMO) one of Perl's laudable principles of "easy things should be easy, and hard things should be possible" and build the language with the assumption of being on top of a rather high quality set of existing concurrency primitives.

Concurrency plus mutability is hard. And idiomatic Java works by mutating state. A language where immutability is idiomatic can be appealing even to somebody who knows that java.util.concurrent exists and has a handy reference to the relevant book.

Stealing a line from from https://github.com/l3nz/SlicedBread - "..the over 400 rich pages of 'Java concurrency in practice' show how hard it is to write and debug a good-mannered multithreaded application in standard Java."

Heh, I wasn't even thinking of that one as the relevant reference, though it's valid. I was thinking of "Concurrent Programming in Java" as it comes from the horse's mouth, but that one is also close to 400 pages.

I don't even try to think about concurrent designs too much at work and sometimes feel guilty about it. Occasionally I'll use or suggest someone use a CompleteableFuture, but there is so much code and irrelevant detail compared to Clojure's "wrap body in (future), done". On the other hand some more junior devs have expressed lack of interest in studying concurrency at all since "we don't really work on concurrent or distributed systems", at which point I have to point out that as a company we serve a giant web application with API entry points from multiple bits of hardware with clients all over making concurrent requests... The road is long.

I highly recommend java devs use the concurrent collections and avoid using the synchronized keyword.

This, using synchronized is a mistake unless you really need to use some exotic collection without an implementation in java.util.concurrent

Not every set of operations you need to synchronize can be squished into a collection operation (add, get, etc.). If all you need to do is make sure things can get and add stuff to a queue or list concurrently, well yah, that's definitely a good place to be. Can also just shove it all off on your DB

Reply on news.ycombinator.com