4 ms·
Maybe if you are taking Java the language in isolation but if you consider the JVM ecosystem than I'll absolutely say the JVM does concurrency better. While the
by jaegerpicker 10y ago
Maybe if you are taking Java the language in isolation but if you consider the JVM ecosystem than I'll absolutely say the JVM does concurrency better. While the JVM offers something like quasar (http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/) which can match go's goroutine and channels plus an actor interface or the really excellent Akka (http://akka.io/ http://akka.io/) for a non blocking async actor framework. Offering a lot more choice than golang's single concurrency pattern. I've written major applications with both go and Akka using Java (and scala) and while both were successful stable and performant it's hard to argue with the JVM's concurrency story.
- Matthias247 10y agoJava for sure has good tools for concurrency, and you listed some of the very interesting choices! However the flexible nature of Java concurrency also has the drawback that you might need to integrate different libraries that utilize different concurrency solutions (blocking threads, actors, non-blocking eventloops) with each other. This can end up in a lot more effort than if you try to use multiple libraries in an ecosystem with a single opinionated concurrency solution (like Go for blocking IO or node for pure nonblocking IO). The weakest ecosystem regarding this is imho C++, where most concurrency/IO solutions only work well if you don't try to also use other solutions in parallel (e.g. QT plus glib plus boost asio plus libuv...).