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
> 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.
Orleans is a similar the same thing to Akka.NET, but its design goals are kind of reversed from Akka's in that it's designed first for non-expert users to build distributed systems. Akka gives you the whole toolbox, and you figure it out from there. Orleans is rather more opinionated and, while it has similar features and concepts to Akka, it has an easier "happy path" for building scalable systems using it.
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.
Can non expert users actually build distributed systems? I mean they can start it, but will it actually give correct results and scale and handle concurrency concerns?
I can't speak to it at Very Large Scales, but I've seen non-experts do pretty well with Akka when strong guardrails are put in place by seasoned developers. No reason to think that Orleans (which I've studied but not used heavily, though that might change with CoreCLR) couldn't pre-bake that a bit. I mean, eventually that sort of thing will fall down, but almost anything will.
Why do people ask questions like this here? let's turn this around for illustrative purposes....why do you use Akka instead of Orleans? Why don't you use Go?
These questions add nothing to the conversation beyond a veiled promotion of someone's pet technology
I'm not sure that's really the purpose. Akka.NET is the incumbent technology. Orleans might be older, but since Microsoft Research is historically bad at popularizing (or even being willing to share) its products, so Akka.NET is the one most people already know about.
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.
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.