Comment by ryanjshaw | Hacker News Reader

Comment by ryanjshaw | Hacker News Reader

Parent Full thread

I've experimented with both; I've done some Akka.net training. My thoughts:

1. Orleans is very clean but highly opionated and this results in what I see as operational shortcomings, e.g. I prefer running discrete Windows services that I can start/shutdown to provide fault isolation and safe upgrades, but this doesn't seem to be directly supported in Orleans (the documentation speaks about "restrictive placement strategies" to ensure certain grains are located in certain silos, but I could never figure out how to achieve that, and it also seems against the design to have such a level of control). If it fits what you need, it's really a nice solution.

2. Akka.net's API is very messy and out-dated, in my opinion; I'll give some examples. You have to inherit from Akka.net classes, which makes me very nervous from a testing standpoint. Messages are untyped. There is no easy way to understand the interface (sequence of valid message flows) to an actor. This suggests maintenance will be tricky after some time away from the code unless you carefully design your actors (yes, arguably this could be said of any code). Documentation for fundamental topics is still incomplete in places (e.g. http://getakka.net/docs/working-with-actors/handling-message...). Persistence still confuses me after reading it 5 times. That all being said, it's a straightforward API clone of something that is proven and accommodating to the different development styles required for a broad range of back-end services.

In Akka you can have typed actors, however you're missing the point.

In the actor model you often end up modeling state machines, and especially in the presence of asynchrony, it is impossible to meaningfully add types to such state machines. Because you see, the full set of messages that an actor recognizes at some point is much less interesting than the set of messages an actor accepts right now.

Another problem is that actors often communicate with multiple other actors at the same time, possibly aggregating data from multiple sources, outputting data on multiple channels. Thus a single actor can expose different APIs, depending on whom it is taking to.

And yet another problem is that often actors act as proxies or supervisors, simply forwarding messages around.

Basically people complaining about the untyped nature of actors are terribly misunderstanding the actor model. Or distributed systems.

You don't add types to state machines, however you can add typed ports and channels to actors. There is no requirement for a single inbox for messages. See kompics http://www.springer.com/la/book/9783642450648

There's a project called Orleankka which lets you use Orleans and virtual actors with Akka style messaging:

https://github.com/OrleansContrib/Orleankka

What do you mean by messages being untyped in Akka.NET? You can inherit from ReceiveActor and register handlers for specific types easily.

Your comment on Akka.NET is spot on. That was precisely my experience with it.

> You have to inherit from Akka.net classes, which makes me very nervous from a testing standpoint.

How do classes make you nervous? Testing support is one of the strongest parts of akka (see Akka.TestKit) - you can even simulate things like networks delays or VM shutdowns.

> Persistence still confuses me after reading it 5 times.

Yes for people not familiar with concepts of eventsourcing, Akka.Persistence can be enigmatic indeed. But you're not forced to do eventsourcing when using Akka.

Reply on news.ycombinator.com