Comparasion to Quasar

73 views
Skip to first unread message

Samyem Tuladhar

unread,
Jun 11, 2015, 9:57:34 AM6/11/15
to reactor-...@googlegroups.com
I am trying to compare frameworks for alternatives to manual thread handling. Has anyone in this board have experience with quasar (http://www.paralleluniverse.co/quasar/) and how it compares to reactor and/or akka? From a high level as an outsider, they all appear to address the same problem domain.

Thanks

Jon Brisbin

unread,
Jun 11, 2015, 10:22:46 AM6/11/15
to Samyem Tuladhar, Reactor Framework
I’m not overly-familiar with Quasar specifically but the approaches to concurrency taken by Quasar and Erlang on the JVM take a very different approach than Reactor. Continuations (Fibers, as Quasar calls them) attempt to transform imperative code into asynchronous code by transparently (to the developer) introducing other processing steps than what are listed in the code. It does this by byte code manipulation and javaagent instrumentation since Java the language doesn’t actually support continuations. IMO this has significant disadvantages that won’t fit all use cases. If your use case can be addressed by Fibers, then it is a (somewhat) nice approach to use. That continuation functionality comes at a price, however.

The various frameworks you listed do address the general problem of high-speed and highly-efficient task dispatching but they all do so in pretty different ways. You can use Akka from Java, of course, but it’s not nearly as integrated an experience as using it how it’s intended, which is from Scala. That is a trade-off you have to make unless you’re already full-bore into Scala, in which case it’s simply a question of a different framework. Quasar (and also Erlang and Clojure) approach concurrency from a different perspective as well, though it’s generally within the same problem “umbrella”. But to use those solutions you need to accept more than just a framework into your application: you have accept an entire “way of doing things”.

The goal of Reactor always has been to provide some of the benefits these other frameworks also provide but to do so with a minimal amount of changing how you want to go about building your app. Reactor can be embedded in your app from any language you choose to use on the JVM and it doesn’t require any special build steps or runtime requirements in order to run it. It strategically lacks some of the features of the other frameworks because to implement them, one would have to bite off more than just adding a Java dependency to your application. You can build an Actor using Reactor but that abstraction isn’t included in the framework proper because we don’t want to assume that everything you do is done using the Actor model. Not everyone’s needs are met by rubber-stamping the Actor model onto everything. That’s why Reactor’s focus on the Stream is so important: it really is the bee’s knees when it comes to Reactive, compositional/functional pipeline processing that includes many of the flexibilities of the Reactor pattern; but it also has other ways to address concurrency to support ultimate flexibility.


Thanks!

Jon Brisbin
Reactor Project Lead

about.me/jonbrisbin | @j_brisbin | @ProjectReactor

On Jun 11, 2015, at 8:57 AM, Samyem Tuladhar <sam...@gmail.com> wrote:

I am trying to compare frameworks for alternatives to manual thread handling. Has anyone in this board have experience with quasar (http://www.paralleluniverse.co/quasar/) and how it compares to reactor and/or akka? From a high level as an outsider, they all appear to address the same problem domain.

Thanks

--
You received this message because you are subscribed to the Google Groups "reactor-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactor-framew...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages