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.
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?
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.
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"
Akka.NET suffers from problems with the Helios transport right now, I don't think the Helios transport do more than a few thousand messages per sec ATM.
That being said, there is a new transport coming in Akka.NET 1.5 where we do 100 000 messages per sec in our experiments, so that is a huge improvement.
But that is still more than 8 times slower than GAM.
The reason for Akka.NET (and JVM Akka) having trouble in this area is that every message comes with a sender ActorRef that needs to be resolved. even if the target doesn't touch that ActorRef.
The serialization mechanism there is also a lot more complicated.
Also includes 1 million message throughput tests for duplex and inbound-only receive. On the inbound side we peak out at about 250k / s on a single connection. Write side is slower at the moment due to lack of batching on flush, but that'll be fixed.
Akka.net wasnt really intended to be a complete port from the start, it was a weekend hack from my part that then grew into what later became akka.net when Aaron joined (akka.actor and akka.remote first).
Then things took off and it got a life of its own.
Now there is an entire sub-ecosystem growing around it in terms of persistence providers, testkits and dependency injection lib integrations.
AWESOME to see :)
I think the point was more that Erlang was produced at considerable expense, so the cost of recreating Erlang for your own project is probably less than the cost of simply producing your project in Erlang.
> I think the point was more that Erlang was produced at considerable expense, so the cost of recreating Erlang for your own project is probably more than the cost of simply producing your project in Erlang.
Fixed! Read your comment, understood it, but I think you probably meant the opposite
Retlang was a pioneer in this space for .NET, sadly it never took off more than some initial hype.
But compared to Akka.NET, Akka on the JVM is battle proven for many years now, running backends for Wallmart, LinkedIn etc. So it is good ground to stand on.
Also, Akka.NET compared to Retlang, if I recall correctly, Retlang did about 300 k messages per sec locally, while Akka.NET does 34+ million messages per sec on the same laptop.
I agree Akka has way more mindshare than Retlang/Jetlang. DRW seem to be happy to throw it over the wall but not promote their stuff. I'm curious about the perf figures. Mike was reporting 2.3m msg/s in 2007 and it's seen a number of perf improvements since then (as has hardware :)). Admittedly, I'm sure it could be optimised further since it just uses classic locks.
And this is a single datapoint, I know, but it's _ridiculously_ stable in my experience.
Literally, I've been telling people to just use Retlang since 2007. So many people still just fire up the threads and locks...
e.g. see this CLI tool for managing proto.actor systems live: https://asciinema.org/a/a1b18jiv703e6eog1o2b7domi
You will be able to send messages to actors, connect to remote nodes etc.
There are also very fine-grained interception points allowing us to plug in things like zipkin.io w/o altering how the user writes their code.