Akka or Reactor [closed]

Answer 1

It is hard to tell at this point because Reactor is still a sketch and I (Akka tech lead) do not have insight into where it will go. It will be interesting to see if Reactor becomes a competitor to Akka, we are looking forward to that.

As far as I can see, from your requirements list Reactor is missing resilience (i.e. what supervision gives you in Akka) and location transparency (i.e. referring to active entities in a fashion which lets you abstract over local or remote messaging; which is what you imply by “distributed”). For “modular” I do not know enough about Reactor, in particular how you can look up active components and manage them.

If you start a real project now and need something which satisfies your first sentence, then I don’t think it would be controversial to recommend Akka at this point (as Jon also noted). Feel free to ask more concrete questions on SO or on the akka-user mailing list.

Answer 2

Reactor is not bound to Spring, it's an optional module. We want Reactor to be portable, a foundation as Jon outlined.

I won't be confident about pushing in production as we are not even Milestone (1.0.0.SNAPSHOT), in that regard, I would have a deeper look at Akka which is a fantastic asynchronous framework IMO. Also consider Vert.x and Finagle which might be adapted if you look either for a platform (the former) or for composable futures (the latter). If you look after a wide range of asynchronous patterns, maybe GPars will provide you a more complete solution.

In the end, we might certainly have overlaps, in fact we're leaning toward a mixed approach (flexible composable eventing, distributed, and not bound to any dispatching strategy) where you can easily find bits from RxJava, Vert.x, Akka etc. We are not even opinionated by the language choice, even if we are strongly committed to Groovy, people have already started Clojure and Kotlin ports. Add to this mix the fact that some requirements are driven by Spring XD and Grails.

Many thanks for your witnessed interest, hopefully you'll have more comparison points in a couple of months :)

Answer 3

This is an excellent question and the answer will change over the weeks to come. We can't make any promises of what inter-node communication will look like right now just because it's too early. We still have some pieces to put together before we can demonstrate clustering in Reactor.

With that said, just because Reactor doesn't do inter-node comms OOTB doesn't mean it can't. :) One would only need a fairly thin network layer to coordinate between Reactors using something like Redis or AMQP to give it some clustered smarts.

We're definitely talking about and planning for distributed scenarios in Reactor. It's just too early to say exactly how it's going to work.

If you need something that does clustering right now, you'll be safer choosing Akka.