Any plans for Vert.x using Loom?

181 views
Skip to first unread message

Haddock

unread,
Dec 30, 2020, 8:14:44 AM12/30/20
to vert.x

Here are some nice blogs from the Jetty team that did some experiments with Loom:


This looks quite interesting and promising? Are there any plans in ther vert.x world to do some experiments with Loom?

Loom:


Julien Viet

unread,
Dec 30, 2020, 9:36:51 AM12/30/20
to vert.x
Hi,

we are thinking to provide a code generated API similar to what we do provide for RxJava that will provide a blocking API for Vert.x.

It sounds easy and quick to implement (as we can fork the existing RX generator and modify it) and provide a similar experience than Vert.x Sync and will help to experiment with Loom.

I believe that anything related to Loom remains very speculative and to be honest I don't have a precise (and personal) opinion on what Loom would effectively provide and which time frame it would be production ready (based on the fact that it took many years to have JDK NIO being actually usable). I'm assuming a lot of people will experiment with it and some will claim that async is dead with bells and whistles, the reality might be different.

After those experiments, it will be interesting to see whether it can be used as a basis for developing a brand new kind of Vert.x or not.

HTH

Julien




--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/1cbe6b6b-1c0d-4246-95b1-376e2e5d380cn%40googlegroups.com.

Haddock

unread,
Jan 2, 2021, 12:32:11 PM1/2/21
to vert.x
jul...@julienviet.com schrieb am Mittwoch, 30. Dezember 2020 um 15:36:51 UTC+1:

I believe that anything related to Loom remains very speculative and to be honest I don't have a precise (and personal) opinion on what Loom would effectively provide and which time frame it would be production ready (based on the fact that it took many years to have JDK NIO being actually usable). I'm assuming a lot of people will experiment with it and some will claim that async is dead with bells and whistles, the reality might be different.

Yes, there is absolutely no deadline for Loom and it can still take a year or maybe 3 till something is ready to be included into some JDK. Using communicating sequential processes (CSP) as proposed by Tony Hoare has been very successful in Go. I believe the variant of CSP applied in Go with those Goroutines (and channels) is one of the reasons of the success of Go for server-side development.

CSP gives from the beginning quite good CPU utilisation, fewer problems with race conditions and deadlocks than with a conventional threading model. If race conditions or deadlocks occur, they are easier to find out and to fix than when using locks, semaphores latches, mutates, etc. However, using a CSP-style approach is not always the best way to go. Depending on the problem sometimes a conventional approach will calculate the result faster. So this will confuse some Java people (not so in Go where there is only a single threading model that can be used) and make adoption harder.
 
After those experiments, it will be interesting to see whether it can be used as a basis for developing a brand new kind of Vert.x or not.

I believe that blocking IO will always be a problem. Therefore all the async APIs for external systems like redis, Mongo, RDBMS, etc. that vert.x already provides will still be useful. Eventually the result is only dropped into some channel instead of invoking some callback handler. 
Reply all
Reply to author
Forward
0 new messages