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