5 ms·

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

Jach 8y ago
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.
- brlewis 8y ago
  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.
  - kimi 8y ago
    Stealing a line from from https://github.com/l3nz/SlicedBread 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."
    - Jach 8y ago
      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.
- itronitron 8y ago
  I highly recommend java devs use the concurrent collections and avoid using the synchronized keyword.
  - opportune 8y ago
    This, using synchronized is a mistake unless you really need to use some exotic collection without an implementation in java.util.concurrent
    - preordained 8y ago
      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

Jach 8y ago

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.

brlewis 8y ago
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.
- kimi 8y ago
  Stealing a line from from https://github.com/l3nz/SlicedBread 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."
  - Jach 8y ago
    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.
itronitron 8y ago
I highly recommend java devs use the concurrent collections and avoid using the synchronized keyword.
- opportune 8y ago
  This, using synchronized is a mistake unless you really need to use some exotic collection without an implementation in java.util.concurrent
  - preordained 8y ago
    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