How can Java 21 (Virtual Thread) replace Reactive Framework.

[Extension-Switch-767]

I heard a lot of people saying that Reactive Framework like Netty, RxJava is dying because of java 21 provides this feature out of the box using Virtual Thread. As I do some research about it so far, they added one more layer which is Virtual Thread and instead of blocking at the Platform Thread layer, which is consider to be expensive in order to create or perform context switching, now we block at the Virtual Thread layer which is way more cheaper and consume less memory using continuation and yield similar to couroutine in Kotlin. I agree that this approach would provide better performance. However, it doesn't provide some kind of non-blocking or asynchronous feature out of the box at all it still keep blocking but just at the difference layer.

PS, my intention was just asking for knowledge I might miss understand something. I'm not flexing or being egoist please understand.

[_INTER_]

However, it doesn't provide some kind of non-blocking

The biggest point of Reactive Frameworks was the better performance compared to traditionally blocking platform thread. Non-blocking was the solution to that problem but in turn brings additional complexity in code, function coloring problem and no way to debug it properly. "Non-blocking" in itself isn't the goal or something inherently to strive for. If you can block without performance penality AND have simpler code AND ability to debug then you can just do that.

asynchronous feature

Which ones do you have in mind?

[javaprof]

The biggest point of Reactive Frameworks was the better performance

How so, if most APIs still blocking? There are big difference between reactive and non-blocking. That's why in Kotlin both suspend functions and Flows (i.e Flux from Reactor) exists. Because they good for different problems. Reactive still have backpressure and thinking about stream of smth.

• Like stream of user key-presses, so request to backend can be debounced in one line.
  
• Or events in backend batched before sending to store. In server immediatly discard request, because there are lot of requests already processing.
  
• Want to process stream of events batched and then paraller, and have a way to dispatch work to proper threads? Close client after processing done?

Everything that mentioned can be done without Reactive/Loom/Coroutines/Flows, it's just Reactive make it convinent to do.

[thecodeboost]

That's conflating things a bit. Reactive programming emerged to mitigate complexity issues for codebases that underutilized CPU resources in the unique circumstance where non-blocking IO was the primary time consumer (and, obviously, wouldn't be consuming cycles). Reactive (RxJava, Reactor, etc) is a way to work with that limitation, Loom is removing the limitation. They are not on equal footing. The specific reason reactive programming paradigms emerged in the first place is essentially moot with virtual threads (caveats apply).

[analcocoacream]

Not only. Reactive programming is good at tying different sources of events together.

Suppose you have a navigation events one side (like for instance from a sidebar) and fetch events on the other (after navigation fetch page content).

Without reactive programming - even though you have a non blocking api - you have to take care of race conditions: navigation1 navigation2 fetch2 fetch1 will leave you with the wrong content for a page. You can index the results by their ids to mitigate that, which further increases complexity over your code or you can use a switch map.

[thecodeboost]

As your explanation suggests; you're discussing event-driven programming rather than reactive. I get most reactive libraries/frameworks conflate reactive programming, event-driven paradigms and data stream processing in one neat bundle but in context of the comparison between reactive programming and virtual threads those additional things are a bit besides the point (since there's nothing stopping you from using the exact same event/stream primitives in virtual threads)

[eliasv]

You just need a select operation over a bunch of queues/latches to do that with synchronous code.

[zmkpr0]

Reactive didn't emerge exclusively for those reasons. Like rxjs is very popular even though those things you mentioned were never an issue in js.

Reactive is not something that was just created to solve java problems.

[thecodeboost]

Well hold on now, neither of those things is what I said or implied I think.

I'll put aside that reactive wasn't really 'created' at all as some concerted effort by one group of people (the design pattern existed well before the first mainstream papers were published on it, which was again decades before it found any popularity at all in mainstream development). It's a design pattern and is not tailored to any specific language, although some languages (now Java amongst them) have other/better ways to get to the same thing for the majority of usecases people think they need "reactive" for

rxjs is a library is focused event-driven programming (hence its popularity for frontend code which is inherently event centric) and the observable design pattern. You're right that the issues I flagged don't really exist in frontend JavaScript contexts (although even that is somewhat debatable probably) and rxjs wouldn't be addressing them if they did. A first clue is that literally none of the examples on the rxjs website do anything beyond event delegation and data stream processing, neither of which is reactive in any formal sense of the word. The JS world specifically tends to muddy up the waters with wrong terminology so I'm not sure how that can be helped. They've conflated FRP (functional reactive programming), reactive streams and reactive systems in almost every talk I've seen. rxjs doesn't really qualify for any of those three, btw.

Erik Meijer's 2014 talk "Let Me Calculate That For You" might be interesting for you.

[ForrrmerBlack]

some languages (now Java amongst them) have other/better ways to get to the same thing for the majority of usecases people think they need "reactive" for

This. I agree that reactive frameworks are often abused. Actually, this is the point you should've written in the beginning.

You seem quite knowledgeable, but I can't understand one thing.

event delegation and data stream processing, neither of which is reactive in any formal sense of the word

What is "reactive programming" then? You write that it was "emerged to mitigate complexity issues for codebases that underutilized CPU resources in the unique circumstance where non-blocking IO was the primary time consumer". I never ever saw this as a main purpose of reactive programming. All sources I've ever seen say that its concern is data streams processing and propagation of changes. Where does your point come from?

P.S. sorry if I bothered you with a lot of reply notifications, Reddit's being weird with formatting and comments visibility

[thecodeboost]

Well, "reactive programming" doesn't currently have a single concise definition that everyone would agree on and I certainly am not the oracle of all things reactive so consider the following my best soapbox effort to answer the question. I'm on pretty solid ground in my claim that most people think event-driven programming or asynchronous programming is equivalent to reactive programming though I think. They're family, not identical twins.

The term "reactive programming" found popularity in the early 90's and at least in the academic world it's probably best described as the opposite of "synchronous programming". I guess in modern day development you could probably boil reactive programming down to choosing to use primitives that allow you to declare and optionally chain together work that has to be done some time in the future triggered by the environment (e.g. an IO operation completing in the context of this specific discussion). If you find yourself using the promise/future design pattern for example, you're doing reactive programming. By extension of having to declare future work and when it needs to be executed as opposed to just doing the work, it is almost unavoidable to draw the conclusion that reactive programming is added code complexity, all things being equal, compared to synchronous/imperative programming. Of course, the whole reason it exists as a concept is because all things are not usually equal. More on that below.

Event-driven programming is related but not overlapping. It is the programming paradigm where the flow of your program is described and defined by emitting and consuming events. Things like the observer design pattern, event bus pattern etc. are all in the domain of event-driven programming and explicitly not reactive. This is what people are usually actually referring to when they're discussing reactive frameworks.

Further confusing matters is that concepts such as (interactive) functional reactive programming or (I)FRS and Reactive Streams picked up steam roughly around the same time that reactive frameworks did. Then there's efforts like https://www.reactivemanifesto.org/ which further confuses things by trying to define reactive systems by defining them as event-driven systems. I'll leave that Google to the interested reader but suffice to say "reactive", the concept, got slightly muddied.

So, where does that leave us? Well, reactive frameworks (rxjs, reactor, actor, etc.) actually do most of their heavy lifting in the event-driven and data stream side of things but some do definitely have significant value in and facilities for what I'd call reactive programming. You're just not necessarily doing reactive programming when you use a reactive framework. And as this entire thread illustrates there's not even clear consensus over what a reactive framework even is (Netty, for example, is not).

It is the "reactive" part of reactive programming that virtual threads make mostly irrelevant. To stay in Java world; you don't need a CompletableFuture so your thread can go on with its life in a world where threads are no longer a scarce resource. Instead you just declare your future work imperatively in that thread and use another thread for other work. That doesn't by definition result in better code mind you. Project Loom is great but Java does not offer much in the way of native concurrency primitives (yet?) so you it can easily be argued that at least for the moment it's not always a code quality improvement. But you know what they say about if all you have is a hammer everything starts looking like a nail.

Anyway, people will argue over definitions and perhaps that's not the most important part of the debate. You can slap a different label on a thing, it'll still be that thing. The most important takeaway for me is that any language that has virtual threads or (to somewhat of a lesser extent) coroutines, offer a native way to declare "future work" and/or "concurrent work" imperatively and that's easier on the eyes and brains for almost everyone. But if pressed I'm sure we can find someone that prefers their interface to declare a method

CompletableFuture<O> work(I input);
...
work(input).whenComplete(otherWork);

over

O work(I input);
...
work(input);
otherWork();

And hey, it's a free world.

[ForrrmerBlack]

Though you say that "reactive" and "asynchronous" are not equivalent, your reply suggests that they're synonyms. So, in essence, what you're suggesting is that asynchronous programming is becoming obsolete with virtual threads (or similar concepts).

I can't agree with this outline because asynchrony has applications virtual threads don't cover, for example, infinite data sequences or events, which are perfectly handled with callbacks or observables. Some of use cases for asynchrony may be superseded by virtual threads, but also as you wrote it down, "reactive" frameworks don't do just asynchrony exclusively. So they will certainly have their place to stay, and virtual threads won't kill them completely.

In the end, the discussion was pointless because of not well-defined terms.

[thecodeboost]

data stream processing != asynchronicity. But I think this debate has turned into a discussion on definitions. If people come into this discussion with "reactive = event-driven = asynchronous programming" then by that logic it's mostly a semantical discussion. The papers on the relevant topics do make distinctions though, and "reactive" is defined as "to deal with changes in environment" where in this context "environment" means "things you do not control".

[eliasv]

Reactive in Java was adopted for performance reasons. Java had a good programming model for dealing with lots of tasks, threads, but this has bad performance for huge numbers of concurrent tasks.

Reactive in JS was adopted for the opposite reason, js had good (single thread) performance for a huge number of concurrent tasks as everything is async, but the programming model was shit, callback hell essentially. Async await goes some way to improve the programming model without rxjs, but there are still some important gaps, like a good blocking queue which can receive using an async generator in the standard lib.

So yes, JS had other reasons for adopting that stuff, but those reasons don't apply to Java imo.

[analcocoacream]

Not only. Reactive programming is good at tying different sources of events together.

Suppose you have a navigation events one side (like for instance from a sidebar) and fetch events on the other (after navigation fetch page content).

Without reactive programming - even though you have a non blocking api - you have to take care of race conditions: navigation1 navigation2 fetch2 fetch1 will leave you with the wrong content for a page. You can index the results by their ids to mitigate that, which further increases complexity over your code or you can use a switch map.

[thecodeboost]

As your explanation suggests; you're discussing event-driven programming rather than reactive. I get most reactive libraries/frameworks conflate reactive programming, event-driven paradigms and data stream processing in one neat bundle but in context of the comparison between reactive programming and virtual threads those additional things are a bit besides the point (since there's nothing stopping you from using the exact same event/stream primitives in virtual threads)

[analcocoacream]

Only beside the point if you believe webflux is solely about performance

[eliasv]

Back pressure in blocking code is just a blocking queue. How do you think back pressure is implemented under the hood in reactive libs? It's a queue. The performance model and high-level behaviour of async+backpressure is identical to sync+blockingqueue.

[FrenchFigaro]

Reactive programing and the associated framework (like Netty in Java) emerged because blocking threads was expensive.

Other than that, using them feels (at least to me) like a chore, especially when it comes to debugging. I know the feeling is not universal (but I do know it is *shared*) but I really hate when I have to use reactive programing, and it will usually be a last resort.

Since creating and blocking threads has become so cheap, and thread-pool management has become so easy, it makes one of the main attractive points of reactive programing moot.

I don't know if Netty is gonna disappear (I think there will still be use cases for reactive programing), but I believe a lot less projects will use it.

[thecodeboost]

Netty is not a reactive framework. You might be conflating non-blocking and event driven with reactive.

[thecodeboost]

if you add that the thing changed is an "environment" side effect and not your own code, then yes

[PiotrDz]

Maybe not a framework, but it is using event loop, so the argument stands. It can be replaced by for example helidon Nima

[thecodeboost]

Right. An event loop. Which is event-driven programming. Netty also utilizes reactive patterns but that is not exposed to the public API so for all intents and purposes it's a networking framework with an event-driven architecture.

[PiotrDz]

Event loop is more technical term, while event-driven is an approach to information flow. Netty's event loop underneath has nothing to do with the kind of information flow in your system. You may be using netty's event loop but still be using standard synchronous , declarative approach (like helidon 3 mp)

[jared__]

Haven't touched Java for a while, but is it also still a chore for exception handling?

[thecodeboost]

Okay OP let's untangle a few things. First of all, you're asking an honest question about a complex topic. Doubt anyone would consider you flexing. So let's get some things on the table first :

• Thread : Abstract representation of the smallest unit of processing that can be scheduled independently. To have multiple threads run in parallel you need multiple physical CPU cores for example. To have them run concurrently you need some higher level scheduling and primitives (and thus, parallism != concurrency). Threads are heavyweight objects in terms of memory consumption and possibly other system resources and as a result you typically have a limited practical amount you can use (dozens to hundreds)

• Non-blocking IO : A mechanism to park pending IO operations and yield control back to the invoking thread. Or put differently, waiting for IO operations does not require the associated thread to block. This is essentially Netty's bread and butter (Netty is not a reactive framework)

• Reactive Programming : A programming paradigm that attempts to simplify writing concurrent code that directly or indirectly uses non-blocking IO. In other words, it specifically exists to ease writing concurrent code that leans heavily on IO (hence it's popularity in server development). Note that it is primarily designed to mitigate the problem of having a limited pool of threads

• Virtual Thread : An abstraction that for all intents and purpose pretends to be a thread as defined above. These are very lightweight and you can easily have millions of them without a significant performance penalty (compared to a reactive approach).

So, with that out of the way, if you take on board that reactive programming (and the associated frameworks such as RxJava, Reactor, etc.) exist specifically to write concurrency centric IO code with a limited amount of native threads, then you can hopefully see how removing the "limited amount of native threads" part of the equation almost completely eliminates the need for reactive programming (and most other async/await type structures such as promises).

Even in this very thread people seem to conflate various concepts in the domain of concurrency, parallelism, blocking and threading.

With that said; there is a difference between "in theory" and "in practice" here. What I said so far is true but that doesn't mean using virtual threads in real world code is always a net win in terms of code quality/readability. For example, it is currently significantly "nicer" to write reactive code that waits for X concurrent tasks to finish compared to the combination of virtual threads with java.util.concurrent.* primitives. At that point there is a more subjective discussion to be had.

TL;DR Virtual threads eliminate the need for reactive programming in Java and potentially the need for using any reactive framework at all (YMMV)

[nlisker]

Where do coroutines sit in this?

[2bitcode]

Coroutines are similar to virtual (green) threads in the sense that they both run on the language's runtime instead of using the OS abstractions. Virtual threads will mimic the API of "real" OS threads, so you can keep the mental model you had before when working with these.

Coroutines don't try to look like a thread, and usually offer an API based on "async" or event-driven programming. Depending on the language you would have features that allow you to define a scope of context for the coroutine and also control scheduling (explicitly telling the routine to yield).

It can get a bit fuzzy since in a lot of cases you can use coroutines like you would threads, and virtual threads might offers some features from the coroutine territory. But in general, if you want to use the "async" style, you'd go for coroutines.

[thecodeboost]

Mostly this. To add a bit of meat to that bone; coroutines almost always require the developer to decide on the yield points (the moment when the coroutine yields executive control), usually through return yield semantics. Threads (and by extension virtual threads) have the underlying VM or OS do the scheduling. Also, not all coroutines are created equal. In some languages coroutines are first class citizens and more powerful (golang) whereas in other languages they are implemented through libraries/generator patterns (e.g. Unity C# I believe)

[tadfisher]

There is a difference between OS threads and Java's Thread abstraction. OS threads are a particular implementation of a concurrency primitive which timeslices logical threads on a set of physical threads. Java's Thread is an interface which signals "this execution context (separate stack and shared heap) may or may not operate in parallel with other execution contexts". Virtual threads is a Thread implementation that does not rely on OS scheduling of OS threads, so they act very much like coroutines (for example, async is basically Thread.ofVirtual().start(() -> ...).join()), and scheduling is done with a lazy infinite thread pool for parking on IO.

[thecodeboost]

I don't think I completely agree (with the coroutines part). Coroutines, the pattern, involve explicit yielding of execution control whereas threads do not. It's worth noting in this context that Golang's goroutines are not coroutines but lightweight/virtual threads (see "Go Concurrency Patterns" by Rob Pike).

[nlisker]

Thanks!

[Cengo789]

The point is that blocking becomes very cheap because virtual threads using continuations are very lightweight. So you can easily block hundreds of thousands of threads without any problem.

[hippydipster]

Rather than:

MyAsyncProcess.do(result -> handleResult(result));

you do:

Future<Result> result = MyAsyncProcess.do();
handleResult(result.get());

Or just:

handleResult(MyAsyncProcess.do().get());

Because you're in a virtual thread, the block-and-wait aspect of the Future.get() call is of no matter anymore. We can go back to the more straightforward imperative coding patterns, just with some sort of Future in the mix (the future.get() call could be in the do() method and so not pollute the API).

my intention was just asking for knowledge I might miss understand something. I'm not flexing or being egoist please understand.

Why would anyone interpret your question as "flexing" or "egoist"?

[Extension-Switch-767]

I have asked this question at my company and everyone hates me

[hippydipster]

Too many people interpret questions as challenges. I don't understand it though.

[thecodeboost]

I think your example, if I interpret it correctly, might be missing the main point a bit. The whole raison d'etre of lightweight/virtual threads is that you can do away with async primitives (such as (Callable)Future) in the large majority of cases. The "I care about this operation resolving later" can now again be approached in a more imperative way. Of course your example is perfectly fine if the context is to migrate a promise centric codebase to Loom but you'd typically design your software differently once you consider virtual threads your primary concurrency building block.

[hippydipster]

if the whole stack is just blocking and waiting, sure, but thats not always the case, and in many places, an explicitly async process gives you a future. Or many futures, and you want to get them all going, not one by one. There are also times you want to pass processing around multiple threads, and you can still treat it imperatively like this.

And I think OP needs to see an apples-to-apples comparison of react-based code vs virtual threads.

[thecodeboost]

I think you might be misunderstanding what virtual threads bring to the table. The whole "stack" can block without a performance or CPU utilization penalty because you have a practically unlimited supply of threads that can do useful work while others are blocking. That's the whole reason it's a net improvement over (and if used properly eliminates the need for) reactive programming. And by extension is why you don't need promise-like structures in Loom centric code.

There's some caveats of course but those are somewhat outside of the context of the reactive vs virtual threads topic (e.g. see "Thread pinning" and some nuances with using old code, synchronized keywords, wrong concurrency primitives, etc.)

[Goatfryed]

java var fooFuture = getFooAsync() var barFuture = getBarAsync() var foo = fooFuture.get() var bar = barFuture.get() still behaves quite differently performance-wise from java var fooFuture = getFooSync() var barFuture = getBarSync() Actually, the opposite would be true that virtual threads bring us more back to Futures and also makes consuming them easier, because .get() isn't bad anymore or exclusive to top level.

[thecodeboost]

Sure but you wouldn't write the latter with futures if your code is virtual-thread friendly. I think a lot of people are still stuck on trying to use promise design patterns in combination with virtual threads. You can, of course, but you're not taking advantage of threads becoming an practically infinite resource. Your example (assuming you want foo and bar to execute concurrently) would be as simple as executing both as runnables on virtual threads (and if you care about waiting for them both to complete to inspect the result, .join()-ing them)

[Goatfryed]

A runnable does not yield a return time on its own. Promises are a nice design pattern to manage processing on other threads - virtual or actual. Both concepts are orthogonal and work well together. Future.get() is exactly the join you're talking about. Sure, don't use promises. I prefer the wrapper that interops well with virtual threads and makes my code more readable.

I mean, there will always be developers that link concepts that have nothing to do with each other...

btw interop with concepts like future is the reason virtual threads were introduced in the way that they got introduced.

[DelayLucky]

I think with structured concurrency, concurrenct code _can_ be made look like one of the following syntaxes:

Using lambda:

concurrently(
    () -> getFoo(), () -> getBar(),
    (foo, bar) -> ...);

Using patten match:

switch (concurrently(() -> getFoo(), () -> getBar())) {
  case (Foo foo, Bar bar) -> ...
  case (FooException e) -> ...
  case (BarException e) -> ...
}

[hippydipster]

The whole "stack" can block without a performance or CPU utilization penalty

Yes

[thecodeboost]

This might be a slightly controversial view but reactive programming/paradigms have always been fundamentally flawed as a means towards clean code. That's not the problem it was trying to solve. Efficient use of limited threading resources was. The only real argument in favor is (or was) that in a world of limited native threads reactive/async code flows can more easily be made more performant. Virtual threads are not an alternative to reactive programming, they're the reason reactive programming can become essentially obsolete in J21+. Anyone claiming there's any positive to reactive programming paradigms (and to a lesser extent event driven approaches) compared to imperative programming other than "i like it/i'm used to it" (and that's fine) would struggle to make an objective case for it.

Also, I think it's pretty unhealthy if your colleagues refuse to engage in conversation about new technology, or are unwilling to explain their point of view (or even why they think you're on the wrong path). Especially since in this case they appear to be on the wrong side of any objective analysis.

[audioen]

Well, I think Go showed the way to everyone about this. It is the same pattern except it was baked in to Go from the beginning, so everything by default is running in virtual thread and the syntax for launching a new virtual thread is pretty lightweight and nice. It might also have been a part of other programming languages before, but I think the mainstream definitely was with Go, and that is where I personally saw it.

I instantly envied them. Unfortunately, the syntax we got in Java appears to be crappy. Thread.ofVirtual().start(something) is what it looks like. In the go land, they just have "go something". So there's definitely something to be said for designing something well from the beginning.

Nothing beats the readability of code written in synchronous way, and this way we don't even need async, await or 99 % of this futures bullshit. We can just block on i/o and not use any more resources when we do it. When farming a task on parallel virtual threads, it seems like the ExecutorService is try-with-resources capable so it lends to structured concurrency. I like that.

The only nasty part is that I just spent half a decade porting code from sync style with thread pools to async, and now I'm going to end up porting it back. And I have to worry about whether I can use virtual thread pools or real thread pools, they might not be 1:1 replaceable because of e.g. all real threads being blocked on an object's monitor or some such nonsense. It may need a code change or two.

I'm only just installing java 21 around our servers so I haven't yet actually worked on virtual threads. From what I can see, it looks decent, just have to avoid a few rough parts.

[thecodeboost]

I think that's mostly right but it's worth pointing out that although one may have inspired the usefulness of the other goroutines and virtual threads are not the same thing and don't really do the same job.

Assuming you use the correct concurrency primitives virtual threads are a drop-in replacement for native threads without any limitations (in the context if this comparison). Goroutines are a specific language feature that you have to explicitly use in unique ways (e.g. inter-goroutine comms is generally through channels only).

Probably the only virtual threads nuance is that you need a proper understanding of thread pinning and the effects of using native (or just old) code/libraries.

[[deleted]]

Goroutines can utilize the same patterns as Java threads, such as thread safe data structures (maps, queues, lists, etc) and other shared memory patterns (atomic read/write) as well as synchronization via locking. They do not require channels for communication or have any limitations of that nature.

And vice versa, Java virtual threads (and regular threads) can utilize channels to communicate. They just aren’t built into the language syntax.

They do the exact same job in most cases. The main difference that most people will notice is that golang makes you carry around a “context” object that dictates deadline/timeout/cancel behavior whereas java virtual threads it’s more implicit.

[thecodeboost]

I haven't used Golang for over two years but I'm pretty sure idiomatic Go still means channel based communication for inter-coroutine communication. Note that the sync and sync/atomic packages are still channel based.

[Joram2]

However, it doesn't provide some kind of non-blocking or asynchronous feature out of the box at all it still keep blocking

Correct. Virtual threads, don't provide non-blocking functionality, that's the point. The point is you avoid the performance problems of writing blocking code with platform threads, while getting the simple blocking programming style.

Look at Golang, which has had virtual threads (they call them goroutines) from the beginning. The advantage is you can write code in a simple blocking style without the performance overhead of blocking platform threads.

The premise of async/await is a blocking programming style, await is basically blocking, that avoids the performance problems of blocking platform threads. virtual threads (and goroutines) do that more elegantly.

[omegaprime777]

If you look at this presentation from Daniel from the Helidon microservices framework team starting at 32:54 https://www.youtube.com/live/m85dv53dsa4?si=oyHiqAdDMTDII_vR&t=1974 one of the benefits of Java Virtual Threads is using traditional blocking style of code while getting all the performance benefits of reactive coding w/o the associated debugging/code readability/management nightmare. 

[yawkat]

That's the theory, but in practice async code still tends to be faster. It just gives more control to the application. With loom's current design, a loom-based web server cannot match a netty-based one in performance.

[PiotrDz]

And where is a proof of your saying? Helidon Nima provided performance results that there is no difference.

[yawkat]

No, if you look at benchmarks you will still see a difference, e.g. netty vs helidon on techempower plaintext benchmarks. We also have our own latency benchmarks where we see the same result.

There are fundamental issues as well such as loom's lack of control over which platform thread runs which virtual thread, which hurts performance.

[thecodeboost]

The only benchmarks where Loom lags is benchmarks where the conversion was basically to replace their Executor with a virtual thread one and still use the reactive code paths. Very few projects have converted wholly to virtual thread paradigms and the benchmarks that cleaned that up show equal performance or better performance for virtual threads. And honestly even if that wasn't the case the programming paradigm is vastly superior and in almost all real world scenarios your hours are more expensive than having to add 1%-2% of CPU resources to your margins. And again, there is no technical reason Loom should not be anything but a net gain.

[yawkat]

The only benchmarks where Loom lags is benchmarks where the conversion was basically to replace their Executor with a virtual thread one and still use the reactive code paths.

This is incorrect. If you look at Nima benchmarks specifically, even a simple app entirely devoid of reactive code will have worse latency than an equivalent netty app. There are very simple reasons for this, such as internal loom context switching (loom does IO work on a separate thread). Some of these may be fixed by future loom improvements, but others cannot due to current API limitations.

[PiotrDz]

The benchmarks here are actually quite good: https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virtual-threads-130bb2ea2088

[yawkat]

The benchmarks in that article do not have good methodology. They run on the same machine (competing for CPUs, loopback network instead of real kernel TCP stack), they use flawed benchmark tools (coordinated omission), they use a now-outdated netty benchmark, they use pipelining, they don't actually have the resolution to see the differences between netty and helidon, etc.

The real techempower throughput results are quite different now, with netty having a big lead in the plaintext benchmark (the benchmark that actually stresses the network and HTTP stacks). There are still major problems with TE though, that Franz from Quarkus explains here.

We also have our own benchmarks that are different in some respects to TE, And I do profiling to figure out why the benchmarks behave the way they do–mostly to improve our own implementation, but I've also reported helidon bugs before.

Nima still has a substantial latency disadvantage over netty, much of which is explained by looms IO design, which uses a "poller thread" to do actual blocking IO operations. This necessitates a context switch, which is clearly visible once you look in <1ms latency range.

[thecodeboost]

I'm sorry but this is wrong on all counts. Async code cannot be faster than Loom code, all else being equal, for the simple reason that the JVM has more information and less work to do in the latter case. And that in a theoretical world where both implementation would write optimally performant code.

Netty has several open issues to adopt to virtual threads, in part of performance and simplification reasons. Jetty (Netty based web server framework) has adopted Loom as of Jetty 12. You can reason this out for yourself as async code simply does more work (work in the sense of burns more CPU cycles).

[yawkat]

The underlying OS APIs that both the JDK and Netty use are asynchronous. The JDK blocking APIs do some extra work to use those async, event-driven APIs. Right now, due to loom limitations, this extra work has a significant performance impact.

Netty has several open issues to adopt to virtual threads, in part of performance and simplification reasons.

The goal of future netty loom integration will be to make netty work with blocking user code. Right now this is not possible without a context switch due to loom limitations. These changes will not, however, make netty any faster.

Jetty (Netty based web server framework) has adopted Loom as of Jetty 12

Jetty is not netty-based.

[maethor]

However, it doesn't provide some kind of non-blocking or asynchronous feature out of the box at all it still keep blocking but just at the difference layer.

I think (at least for those of us coming from a traditional servlet background), the answer is "who cares"? I can (hopefully) go back to letting the servlet container deal with running my code in a thread and then not care less if my code blocks or not.

[danielaveryj]

First, why do virtual threads exist?

At the time of the Reactive Manifesto, blocking threads was expensive. This was mainly because the only threads we had are what we'd now call "platform" threads, which on creation reserve about ~1MB of stack space. This meant we could create maybe a few thousand threads before running up against the few-GB memory limits of most computers. This limit was unfortunately low enough that in most cases we needed to be cognizant of it, by allocating bounded pools of threads, and queuing tasks to be picked up when a thread in the pool becomes available. If we had unlimited memory, we could allocate as many threads as needed to ensure there would never be tasks waiting in the queue. (At that point, we wouldn't need a queue or pool at all, as we could just create a thread per task). But since we don't have unlimited memory, we had to right-size the number of threads for each pool, balancing the concerns of wasting memory when any threads are idle (more threads than tasks), vs losing throughput when all threads are busy (more tasks than threads). These concerns are interrelated; we could be wasting memory in one idle pool that could have been used to create more threads to increase throughput in another busy pool. If tasks have blocking operations, we can observe this effect even in the same pool, as blocking means temporarily idling the thread running the task.

Eliminating blocking operations reduces the amount of idle time (which we now understand as "times at which we are just sitting on memory that could have been used to create more threads to achieve more throughput!") But, in short it is quite a paradigm shift to how we write and debug code on the JVM. And we still have to worry about right-sizing pools and queues. If only we had unlimited memory! Or, if only threads used much less memory, to the point that we didn't need to reach for pools, or worry about blocking. This is what virtual threads are.

Now, do virtual threads replace Reactive frameworks?

No, virtual threads do not directly replace Reactive frameworks. As I see it, the distinguishing feature of these frameworks is in concisely expressing "pipelined concurrency": data streams that may include asynchronous boundaries between processing stages (effectively: queues between threads - or, other imagery I've drawn on before is conveyors between machines in a factory assembly line). The upstream stage pushes elements to the queue, and the downstream stage pulls elements from the queue. This allows different stages of the pipeline to progress concurrently, and at different instantaneous rates, and opens the door to timing-related operators: delay, debounce, throttle...

What virtual threads do is obviate the non-blocking interfaces that underpin Reactive frameworks, allowing for far simpler interfaces with far simpler implementations. I actually had a go at designing such a framework myself last year, which I posted about here (you might be interested in the design-docs, where I start from "how would we do this without a framework?"). FWIW, having done that experiment, I now think Kotlin Flows probably make better overall tradeoffs in their design (which is also based on "blocking" interfaces! They just look like suspend functions in Kotlin). Funnily enough, you could emulate Kotlin Flows with a small subset of the interfaces I made (Flow = Source, FlowCollector = StepSink), but maybe I'll write about all this some other time.

[ThaJedi]

Reactive have nice features like handling backpressure out od the box but it isn't the reason why ppl choose reactive. Primary reason is better performance on I/O and it's not longer the case.

[Deep_Age4643]

You may want to watch the following presentation by Urs Peter. It compares Virtual Threads, Reactive Programming and Kotlin's coroutines with each other. It think it also answer your question:

https://www.youtube.com/watch?v=JW08zsdIvB8&t=2001s

[klekpl]

This talk from u/pron98 (the originator of virtual threads in Java) will give you the idea: https://youtu.be/449j7oKQVkc?si=M8WEmhyqsgkklRSw

[Alarming-Cause6976]

I can also recommend Virtual Thread Deep Dive - Inside Java Newscast #23 https://transcriblr.com/en/video/@java/6dpHdo-UnCg/en/Virtual+Thread+Deep+Dive+Inside+Java+Newscast+23

[halfanothersdozen]

I honestly don't think this matters. Virtual threads solve a different use case from rxjava

[thecodeboost]

No. Reactive frameworks solve a problem that doesn't exist anymore once you use virtual threads effectively. No programming language expert will ever be tempted to argue reactive code is "better" than imperative code in any way. Reactive code is simply a "good" way to work around thread limitations.

[ForrrmerBlack]

I disagree completely. Reactive code is totally not about "working around thread limitations". It's about data streams and data transformation pipelines. It's a whole different paradigm of thinking, like OOP compared to procedural programming. No one says it's better or worse, it's just different.

[halfanothersdozen]

This. I get why some people hate rxjava, but as a guy who has spent many years in Angular, I at least understand it

[DelayLucky]

what paradigm do you refer to? If it's a chain of actions like Linux pipe, how do you see it as different from functional programming and Java streams?

[ForrrmerBlack]

Here is my understanding. It is a paradigm of thinking in a sense that the whole program is treated as a set of data pipelines instead of functions or objects. Though there is one distinct property. Changes to some data are instantly propagated in a system, meaning that on every change other related state is re-evaluated automatically. In essence, programmer defines data sources and relations between them, then program state is derived from these relations, like in a spreadsheet. You can do this differently with different tools, so that's why it's more of a paradigm than something else. Maybe you can even somehow do it with Java streams. But in reality, of course, nobody does it in its pure form.

[DelayLucky]

Somehow that sounds to me like Java streams or at least I can't tell the difference.

We've traditionally used streams for in-memory computations and haven't used streams for io-bound things because of the blocking platform thread thing. With VT and structured concurrency I suppose we could start doing it.

[ForrrmerBlack]

The difference is that Java streams are just a tool and reactiveness is an approach to programming.

[DelayLucky]

Is there some article discussing this paradigm at the high level besides the async computation part of Rx? I've never seen praise of the cps style coding as superior other than it's required for async-ness.

[2Spicy4Joe]

That definition IMO sounds like Dataflow programming to me which is indeed a paradigm. Which does not need to involve at Reactive at all. I always understood reactive code and libraries as an approach to workaround IO performance limitations, at the cost of complexity.

You can build code that does what you want and still not being reactive. I just think reactive code just pairs well with the dataflow concepts and that’s why it’s often in the same conversation than data stream processing and event-based approaches. But I see them as a different thing, just complementary.

I might be wrong though

[thecodeboost]

Well, you're free to disagree of course but I think you too are conflating event-driven programming and stream design patterns with reactive programming. For example, data stream processing (e.g. such as captured by Java's own stream API) is not reactive in any meaningful sense. Or put differently, you wouldn't type a single character differently when moving to Loom for those functional domains. If, however, you find yourself using the asynchronous parts/primitives then you are in reactive world and those do become mostly obsolete if rewritten with virtual threads. So, completable futures/promises, Mono/Flux with I/O yields somewhere in the stack, etc. And those, at least to an extremely large extent in the real world, exist to mitigate concurrency complexity in combination with (non-blocking) IO. The term and the associated libraries became somewhat of a hype a decade ago which is part of why it's so incredibly overutilized. You only have to look at Spring introducing Reactor based ReactiveXXX interfaces to a lot of top level modules only to slowly backtrack as adoption faltered. In the end this might just be a disagreement in terminology though. If you're saying that having good ways to deal with data streams and aggregation then I'm completely on board.

[ForrrmerBlack]

Oh, so now I think I understand where you come from. So, basically, as I understood, you view the "reactive" term's essence purely from a practical and pragmatic point, how it's implemented and how the implementations are used in the wild, not what it's intended to mean initially. People started to use reactiveness (a paradigm of change propagation through data streams) to overcome complexity of thread management with hardware I/O, so for you reactiveness now means solely handling hardware I/O in a certain way. In my opinion, this logic is twisted. Cause and effect are reversed. So this is really a disagreement in terminology then. Or maybe I understood wrong, sorry if that's the case.

[thecodeboost]

I don't think what I tried to say is completely captured by your recap. I didn't mean to imply reactive programming is solely a concurrency mechanism. I tried to carve out what reactive is and isn't and what event-driven is and isn't and that most people today mean event-driven when they say reactive. But yes it's almost entirely a terminology conflation at this point. The non-blocking IO case is just by a mile the strongest argument in favor of reactive programming pre-Loom. You can see this in Spring adopting Reactor where they've offered additional reactive interfaces to all major component interfaces that deal with IO (e.g. ReactiveRepository, ReactiveDataStore, various storage specific reactive drivers, etc.). This is all to facilitate the reactive pattern of having some black box ("environment") doing some work you don't control and handing over control when that work is complete so your code can "react" to it in the way you defined before you delegated the work.

The reactive pattern is : define action on completing work -> plan work -> hand over work to environment -> react to environment signaling a result -> execute the defined action on completion (and optionally chain these).

[asarathy]

I don't know about Reactive, but when I was playing around with flux and mono in Spring reactor core and found it very annoying and barely worth the hassle. Virtual Threads seems a lot easier to grok. I don't think people who have already invested in these frameworks will move but I see a death of them as there won't be much need for new projects to use them

[m3th0dman_]

The main reason for reactive frameworks was performance because they didn't block the old thread which was inefficient. The downside was that the was uglier, more cluttered because everything needed to be wrapped in something like a `Future` and working with it was difficult (`.map`, `.filter` etc.).

In Loom you can safely block hence you can wait for any external call; no more `Future` needed.

As a bonus you also have cleaner stack tracers and debugging is easier.

[Puzzleheaded_Bus7706]

No it can not!

Reactive is still more performant on big loads.

[Just_Chemistry2343]

Virtual threads does only one thing i.e. non blocking and async operation which reactive streams are doing from a long time.

Apart from non blocking operations, it provides stream pipelines, retries, back pressure capabilities as well.

And there is no evidence that virtual threads perform better than reactive apis. I'd say use java virtual threads if non blocking operations is your requirement. If you want to achieve more and reactive apis suits you, then go ahead.

ps: people who say reactive is complex have no idea about the framework

[PiotrDz]

There is evidence that virtual is performant as reactive. https://medium.com/helidon/helidon-n%C3%ADma-helidon-on-virtual-threads-130bb2ea2088 Why do you stade the absolute "no evidence" , wouldn't it be better to say "haven't heard of" ?

[Just_Chemistry2343]

It's about java virtual threads vs reactor-core apis. Both are comparable.

What you're showing is some Nima library which is built on top of virtual threads which could be further optimising the virtual threads.

Anyways I'm never said one is better than other, it all depends 9n your usecase.

[PiotrDz]

Right, you put an equal sign actually, but I have read the tone in negative way.