3 ms·

Not sure why it should be trusted more than Akka or Akka.Net. Akka is much much more than just "actors".

by ex3ndr 10y ago

jrs95 10y ago
I think part of the appeal is that it's built on gRPC, so this could probably be expanded to any of the supported languages on that platform.
Matthias247 10y ago
It's from one of the main authors of Akka.Net, so it should deserve a good amount of trust. Although Akka.Net was of course in main ways a quite straightforward port of the Java code, which means the design credit there goes to the original Akka developers.
RogerAlsing 10y ago
Founder of both Akka.NET and Proto.Actor here. Right now, Proto.Actor-dotnet should not be trusted more than Akka.NET. Akka.NET is production ready and has a huge community. has commercial support etc. There are however a fair number of design issues that I dislike personally which led me to start Proto.Actor The .NET implementation of proto.actor is in alpha version right now. We are building and stabilizing the Go version first, which already is used in major production systems.
- megakid 10y ago
  Roger, lurker on Akka.NET and about to start an Akka.NET PoC at work - proto.actor looks interesting - Can you elaborate on the design issues you have with Akka.NET?
  - RogerAlsing 10y ago
    Sure. Serialization and the concept of the ActorRef. They both go hand in hand. in Akka/NET, ActorRefs are contextual, they belong to a given ActorSystem. This means that when they are serialized, the serializer needs to be able to know how to transfer and rebind this context on serialization and deserialization. To make it more complex, ActorRefs can be embedded in other messages. There are a few other primitives also that are contextual and serialized. This limits the options you have in terms of serializers. It also puts a massive tax on the framework in terms of maintenance. ActorRefs are also "resolved" when deserialized, so the deserializing system has to figure out which actor is targeted. This lookup is slow due to parsing and scanning of actors and their children. This makes network communication speed suffer _a lot_. The configuration DSL HOCON is also tightly integrated with the entire infrastructure, making it hard to reason about what is going on and what parts of the config the current piece of code actually sees. Akka/NET also lacks good interception points, its hard to hook into actors and monitor them. There are just too many moving parts for my own liking. I did blog about some of the problem areas in my POV about a year ago: https://rogerjohansson.blog/2016/03/13/random-things-learned-building-akka-net-part-1/ https://rogerjohansson.blog/2016/03/13/random-things-learned... So the issues are really both on a performance level and at a maintenance level. The mindset in Akka.NET have been more "lets build everything ourselves from scratch to match the JVM" and in proto.actor "lets re-use proven tech and glue them together, with minimal code"

Not sure why it should be trusted more than Akka or Akka.Net. Akka is much much more than just "actors".

by ex3ndr 10y ago

Not sure why it should be trusted more than Akka or Akka.Net. Akka is much much more than just "actors".

jrs95 10y ago

I think part of the appeal is that it's built on gRPC, so this could probably be expanded to any of the supported languages on that platform.

Matthias247 10y ago

It's from one of the main authors of Akka.Net, so it should deserve a good amount of trust. Although Akka.Net was of course in main ways a quite straightforward port of the Java code, which means the design credit there goes to the original Akka developers.

RogerAlsing 10y ago

Founder of both Akka.NET and Proto.Actor here. Right now, Proto.Actor-dotnet should not be trusted more than Akka.NET. Akka.NET is production ready and has a huge community. has commercial support etc. There are however a fair number of design issues that I dislike personally which led me to start Proto.Actor The .NET implementation of proto.actor is in alpha version right now. We are building and stabilizing the Go version first, which already is used in major production systems.

megakid 10y ago
Roger, lurker on Akka.NET and about to start an Akka.NET PoC at work - proto.actor looks interesting - Can you elaborate on the design issues you have with Akka.NET?
- RogerAlsing 10y ago
  Sure. Serialization and the concept of the ActorRef. They both go hand in hand. in Akka/NET, ActorRefs are contextual, they belong to a given ActorSystem. This means that when they are serialized, the serializer needs to be able to know how to transfer and rebind this context on serialization and deserialization. To make it more complex, ActorRefs can be embedded in other messages. There are a few other primitives also that are contextual and serialized. This limits the options you have in terms of serializers. It also puts a massive tax on the framework in terms of maintenance. ActorRefs are also "resolved" when deserialized, so the deserializing system has to figure out which actor is targeted. This lookup is slow due to parsing and scanning of actors and their children. This makes network communication speed suffer _a lot_. The configuration DSL HOCON is also tightly integrated with the entire infrastructure, making it hard to reason about what is going on and what parts of the config the current piece of code actually sees. Akka/NET also lacks good interception points, its hard to hook into actors and monitor them. There are just too many moving parts for my own liking. I did blog about some of the problem areas in my POV about a year ago: https://rogerjohansson.blog/2016/03/13/random-things-learned-building-akka-net-part-1/ https://rogerjohansson.blog/2016/03/13/random-things-learned... So the issues are really both on a performance level and at a maintenance level. The mindset in Akka.NET have been more "lets build everything ourselves from scratch to match the JVM" and in proto.actor "lets re-use proven tech and glue them together, with minimal code"