Why not Akka/Akka.net? It looks more mature framework with bigger community and you can find much more resources about it.
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 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.
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.
I'm not sure claims to Akka.NET's maturity hold water relative to Orleans. Akka proper has a lot of miles on it, but so does Orleans, and I'm not sure Akka.NET is as heavily tested and stressed as Orleans.
These questions add nothing to the conversation beyond a veiled promotion of someone's pet technology
Whenever you're seeing a new technology that seems to do the same thing as a pre-existing technology, I think it's perfectly sane and reasonable to ask, "What does $NEW_THING do differently from $THING_I_ALREADY_USE?" For starters, it lets you get up to speed on its merits much more quickly. You only need to go over the memetic equivalent of a patch file rather than having to read the entire spec.
Ooohh i love this sentence ;)
And yes - it is only sane and reasonable to ask.. but should be mandatory !!