Netty and Project Loom

Question

I may be wrong, but as far as I understand, the whole Reactive/Event Loop thing, and Netty in particular, was invented as an answer to the C10K+ problem. It has obvious drawbacks, as all your code now becomes Async, with ugly callbacks, meaningless stack traces, and therefore hard to maintain and to reason about.

Go's language with goroutines was a solution, now they can write Sync code and also handle C10K+. So now Java comes up with Loom, which essentially copies the Go's solution, soon we will have Fibers and Continuations and will be able to write Sync code again.

So the questions are:

1. When the Loom is released in production, doesn't it make Netty kinda obsolete?

2. If we have Fibers and Continuations in Java, can we write nice Sync code and be ok with C10K+ without Netty?

3. Are there any advantages, for performance or solving C10K+, in writing Async code and using Netty, after production release of Loom?

I understand that Netty is more than just Reactive/Event Loop framework, it also has all the codecs for various protocols, which implementations will be useful somehow anyway, even afterwards.

Selfrising

same question here reddit.com/r/java/comments/d9nxpo/… – Heterosis

@Heterosis Also, github.com/netty/netty/issues/8439 – Selfrising

As far as I know, continuations won't be available in Loom, they are internal – Juliettajuliette

@Juliettajuliette Internal in JVM? Eventually, when Loom is merged into JVM, they may be called internal, yes 🤷🏻‍♂️ – Selfrising

@Selfrising I mean that they won't be exposed via a public API – Juliettajuliette

Answer 1

I'm focusing on the reactive parts of Netty because those you seem to mostly want to address answering on a general level:

Currently reactive programming paradigms are often used to solve performance problems, not because they fit the problem. Those should be covered completely via project Loom.

However, some problems may remain where the reactive programming approach makes sense and is more straight forward to read than imperative code. Reactive frameworks are typically stream oriented and are well suited to combine elements and operations on different entity/data streams. They also provide straight forward local event bus solutions with their provider/subscriber model. In such cases the reactive model might still be the best choice, performant and more readable than an imperative approach. But indeed, project loom should make all the "misuse" due to lack of better support in the native language structures obsolete.

Renzo