4 ms·

Why not Akka/Akka.net? It looks more mature framework with bigger community and you can find much more resources about it.

eropple 10y ago
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.
- brianwawok 10y ago
  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?
  - eropple 10y ago
    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.
ryanjshaw 10y ago
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-messages 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.
- talles 10y ago
  Your comment on Akka.NET is spot on. That was precisely my experience with it.
- polskibus 10y ago
  What do you mean by messages being untyped in Akka.NET? You can inherit from ReceiveActor and register handlers for specific types easily.
- bad_user 10y ago
  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.
  - jamesblonde 10y ago
    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 http://www.springer.com/la/book/9783642450648
  - macca321 10y ago
    There's a project called Orleankka which lets you use Orleans and virtual actors with Akka style messaging: https://github.com/OrleansContrib/Orleankka https://github.com/OrleansContrib/Orleankka
- Horusiath 10y ago
karma_vaccum123 10y ago
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
- bunderbunder 10y ago
  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.
  - yazr 10y ago
    "memetic equivalent of a patch file" Ooohh i love this sentence ;) And yes - it is only sane and reasonable to ask.. but should be mandatory !!

eropple 10y ago

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.

brianwawok 10y ago
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?
- eropple 10y ago
  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.

ryanjshaw 10y ago

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-messages 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.

talles 10y ago
Your comment on Akka.NET is spot on. That was precisely my experience with it.
polskibus 10y ago
What do you mean by messages being untyped in Akka.NET? You can inherit from ReceiveActor and register handlers for specific types easily.
bad_user 10y ago
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.
- jamesblonde 10y ago
  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 http://www.springer.com/la/book/9783642450648
- macca321 10y ago
  There's a project called Orleankka which lets you use Orleans and virtual actors with Akka style messaging: https://github.com/OrleansContrib/Orleankka https://github.com/OrleansContrib/Orleankka
Horusiath 10y ago

karma_vaccum123 10y ago

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

bunderbunder 10y ago
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.
- yazr 10y ago
  "memetic equivalent of a patch file" Ooohh i love this sentence ;) And yes - it is only sane and reasonable to ask.. but should be mandatory !!