Comment by ssijak | Hacker News Reader

Top New Best Ask Show Jobs

Comment by ssijak | Hacker News Reader

There are already many different libraries or approaches to concurrency and parallelism on JVM.

- http://www.baeldung.com/java-completablefuture Promises

- http://vertx.io/ Event Loop

- https://akka.io/ and http://www.paralleluniverse.co/quasar/ Actors

- https://projectreactor.io/ and https://github.com/ReactiveX/RxJava Reactive, event-based

- https://kotlinlang.org/docs/reference/coroutines.html Kotlin coroutines. Something like Project Loom from what I gathered from the article. Can be easily used as lightweight threads, async/await, actors, etc.

- Clojure with its own mix https://purelyfunctional.tv/guide/clojure-concurrency-the-ul...

Actually, Quasar is more than actors - it also implements true, actual fibers/coroutines, using bytecode rewriting (essentially turning each async function into a state machine).

My understanding of all these projects is that you have to change your style of coding / have more complex APIs, or they're just syntactic sugar over heavyweight threads.

What loom seems to offer is the best of both worlds; going back to writing simpler code (e.g. regular "blocking" io code) while scaling much better.

"blocking" io code would be blocking.

Every IO library would need to migrate to something non blocking. This might happen with some - currently some use Netty and NIO - but e.g. JDBC drivers are synchronous.

I believe the article mentions making the java.io package aware of fibers.

Yes you're right, though it would be a miracle - I hope for it ! - if this can be done without changes to existing code.

> have more complex APIs, or they're just syntactic sugar over heavyweight threads.

I am pretty sure that's not the case with Kotlin coroutines :)

Reply on news.ycombinator.com