I am now using Reactor to build a reactive system, and to a certain extent using Kotlin Coroutine.
But I am looking forward to the birth and popularity of Loom.
Maybe in the future we will face the problem of migrating from Reactor to Loom.
I hope it will be low cost and painless.
Does the community have plans for this? Is there a plan to provide corresponding solutions?
Looking forward to your answers.
@kevinten10 It is my personal opinion.
Technically, the Reactor Project has nothing to do with the Loom Project, except some minimal integration which lets one use VirtualThread from Loom to runs async ops using map instead of flatMap. Conceptually, Reactor brings Functional and Reactive Programming into software development and allows focusing on WHAT you do instead of HOW you do that (e.g. functional declarative vs structured imperative).
That all said, if you use Project Reactor because of Mono only and you do not rely on and you don't use the whole power of functional API it gives - well, be ready to rewrite your code completely in 2-3 years once Loom going to be available. Be prepared to use .block() operator to transform your functional Mono<T> into imperative value T and that is basically it.
Otherwise, if you use all the power of Project Reactor and build a complete stream processing solution - think twice if you need Loom and what it offers to you that Reactor does not. Do the same another way around - think if the Loom ever offers you the same number of operators that enable you to manipulate over your async executions easily.
HNY,
Oleh
It is still early to commit to anything, but as @OlegDokuka said it is not going to be an either-or choice. Reactor is already very performant, but using Loom may relax the strong constraint of avoiding blocking calls inside reactive operators, so users may perform more imperative business logic inside of operators like map...
We might also introduce some integrations, like a Scheduler that liberally starts workers as fibers (no ttl, no upper limit on the number of tasks, as opposed to what Schedulers.boundedElastic() does)
I want to use Reactor to simplify asynchronous programming.
Can I understand as follows:
The difference between Reactor and Loom, similar to using java8 Stream API.
Used for _streaming programming_ and _functional programming_.
Most helpful comment
@kevinten10 It is my personal opinion.
Technically, the Reactor Project has nothing to do with the Loom Project, except some minimal integration which lets one use
VirtualThreadfrom Loom to runs async ops usingmapinstead offlatMap. Conceptually, Reactor brings Functional and Reactive Programming into software development and allows focusing on WHAT you do instead of HOW you do that (e.g. functional declarative vs structured imperative).That all said, if you use Project Reactor because of
Monoonly and you do not rely on and you don't use the whole power of functional API it gives - well, be ready to rewrite your code completely in 2-3 years once Loom going to be available. Be prepared to use.block()operator to transform your functionalMono<T>into imperative valueTand that is basically it.Otherwise, if you use all the power of Project Reactor and build a complete stream processing solution - think twice if you need Loom and what it offers to you that Reactor does not. Do the same another way around - think if the Loom ever offers you the same number of operators that enable you to manipulate over your async executions easily.
HNY,
Oleh