9 ms·

Proto Actor – Fast distributed actors for Golang and C#

72 points by cube2222 10y ago

partisan 10y ago
I am interested and I will certainly read the Go version of the documentation, but the .NET of the docs are showing Go code instead. http://proto.actor/docs/dotnet/hello%20world http://proto.actor/docs/dotnet/hello%20world
- jjuel 10y ago
  Yeah I was going to mention this as well. Wanted to look at C# code and kept finding the Go code in the Docs.
- hudo 10y ago
  And im getting bunch of 404s for .net docs. Which means its not really a serious project
  - protomyth 10y ago
    Tried to click on the "Books" link and got a 404. I get the feeling they really aren't ready for visitors yet.
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"
deleted 10y ago
[deleted]
mi100hael 10y ago
.NET and Go are a weird pairing, especially since the library isn't actually "cross-platform." It's two separate implementations. I wonder what the impetus was to develop this library on those two particular platforms, especially since there's already Akka.NET and most people can't shut up about how much they love Goroutines as a concurrency primitive.
- UnpossibleJim 10y ago
  I have to imagine that the .NET application is client side and GO is used server side. .NET has released some distros that will release to Linux systems (though, to be honest, I have never actually tried implementation, so this is all conjecture =/ . Have they gone to Mac, at all? I really don't know. Java would seem a better choice, depending on what they are doing with it, but with Azure, maybe some back end systems run better using Azure and GO...... as you have surely noticed, by this point, I'm spitballing out of my realm, but it is a curious pairing, as you say.
- Matthias247 10y ago
  I think for a communication framework cross-platform has a different meaning then for a simple program or library. I would interpret cross-platform here as "interoperable between platforms", or I can connect one Actor on platform A to another Actor on platform B. IMHO that's something really desireable, because it doesn't one to using a single programming language on a bigger distributed system.
- saturn_vk 10y ago
  The author of this wrote Akka.net first, then wrote GAM (the original name of this project, supporting only go), then implemented the net counterpart
KirinDave 10y ago
We should be really skeptical of (or perhaps we could charitably say, "We should contextualize these,") speed claims. Akka does well in benchmarks too, until you put significant memory pressure on the VM and find it handles less gracefully under load than a more JVM-natural approach using approaches in java.util.concurrent. Actor-based approaches with hundreds of thousands of actors are really amazing, powerful and often simpler than equivalent channel based systems, conceptually. But they require special GC considerations to be made "efficient" of a really high level of mechanical sympathy to make sure you aren't creating pathologically bad situations for the garbage collector.
- macintux 10y ago
  My favorite conference talk is about the multiple facets of Erlang that combine to make it such a great language. Take an opinionated language, an opinionated VM, and a focus on a specific problem space, and magic happens. Take one or two features from Erlang into another language, and you have meh.
  - KirinDave 10y ago
    I think the Actor paradigm is valuable as a modeling tool and is widely dismissed these days by arguments I don't think are actually very valid. But what doesn't work is trying to slavishly copy the Erlang/Pony style without those considerations.
  - vvanders 10y ago
    Considering the production system that the Erlang VM has been deployed to(and the length of time it's existed and thrived) it's hard to make an argument to re-invent it in another language. If that's what your domain space needs, use the BEAM and find a way to talk to it for the parts that you can't move to Erlang.
    - dgfgfdagasdfgfa 10y ago
      It's not hard to justify; that's laughable. It's simple redundancy!
sly010 10y ago
Most of my non trivial goroutines are organized like this: func actor_foo(things) error { set_up_stuff() defer clean_up_stuff() for { select { case msg := <-messages: switch msg.(type) { case *Bla: } case <- other_messages: case <- errors: case <- signals: return nil } } } I recognize there is more to the actor model than just message loops, but I found that an explicit for-select-switch results in better overall readability.
- bmurphy1976 10y ago
  Is signals your "done" channel?
  - sly010 10y ago
    I was just trying to convey an example. I usually "signal" that the parent wants to stop this "actor" for some reason (e.g graceful shutdown). If parent need a "done" channel, it passes it in and "actor" closes it on its way out. Cleanup usually "signals" children and waits for them to be "done". Sometimes "done" is just signalled by the goroutine returning and it is wrapped in parent somehow. But every time I try to formalize it into some "framework" my abstraction fails.
- scarnie 10y ago
  the only challenge here is that upstream senders will block when your channel(s) are full. This is not inherently bad, but if you have a circular dependency, you can deadlock because queues (channels) are bounded and may fill up. There are solutions to that too, but you have to build that in
stcredzero 10y ago
I'm getting a "Page not Found" from this link.
macintux 10y ago
I've captured a few other open source actor implementations: https://gist.github.com/macintux/6349828#other-actor-implementations https://gist.github.com/macintux/6349828#other-actor-impleme...
RogerAlsing 10y ago
One of the major things will be the tooling around it. As we work with a well defined schema. we can create tools that work for all implementations. e.g. see this CLI tool for managing proto.actor systems live: https://asciinema.org/a/a1b18jiv703e6eog1o2b7domi 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.

72 points by cube2222 10y ago

I am interested and I will certainly read the Go version of the documentation, but the .NET of the docs are showing Go code instead. http://proto.actor/docs/dotnet/hello%20world http://proto.actor/docs/dotnet/hello%20world

jjuel 10y ago
Yeah I was going to mention this as well. Wanted to look at C# code and kept finding the Go code in the Docs.
hudo 10y ago
And im getting bunch of 404s for .net docs. Which means its not really a serious project
- protomyth 10y ago
  Tried to click on the "Books" link and got a 404. I get the feeling they really aren't ready for visitors yet.

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"

deleted 10y ago

[deleted]

mi100hael 10y ago

.NET and Go are a weird pairing, especially since the library isn't actually "cross-platform." It's two separate implementations. I wonder what the impetus was to develop this library on those two particular platforms, especially since there's already Akka.NET and most people can't shut up about how much they love Goroutines as a concurrency primitive.

UnpossibleJim 10y ago
I have to imagine that the .NET application is client side and GO is used server side. .NET has released some distros that will release to Linux systems (though, to be honest, I have never actually tried implementation, so this is all conjecture =/ . Have they gone to Mac, at all? I really don't know. Java would seem a better choice, depending on what they are doing with it, but with Azure, maybe some back end systems run better using Azure and GO...... as you have surely noticed, by this point, I'm spitballing out of my realm, but it is a curious pairing, as you say.
Matthias247 10y ago
I think for a communication framework cross-platform has a different meaning then for a simple program or library. I would interpret cross-platform here as "interoperable between platforms", or I can connect one Actor on platform A to another Actor on platform B. IMHO that's something really desireable, because it doesn't one to using a single programming language on a bigger distributed system.
saturn_vk 10y ago
The author of this wrote Akka.net first, then wrote GAM (the original name of this project, supporting only go), then implemented the net counterpart

KirinDave 10y ago

We should be really skeptical of (or perhaps we could charitably say, "We should contextualize these,") speed claims. Akka does well in benchmarks too, until you put significant memory pressure on the VM and find it handles less gracefully under load than a more JVM-natural approach using approaches in java.util.concurrent. Actor-based approaches with hundreds of thousands of actors are really amazing, powerful and often simpler than equivalent channel based systems, conceptually. But they require special GC considerations to be made "efficient" of a really high level of mechanical sympathy to make sure you aren't creating pathologically bad situations for the garbage collector.

macintux 10y ago
My favorite conference talk is about the multiple facets of Erlang that combine to make it such a great language. Take an opinionated language, an opinionated VM, and a focus on a specific problem space, and magic happens. Take one or two features from Erlang into another language, and you have meh.
- KirinDave 10y ago
  I think the Actor paradigm is valuable as a modeling tool and is widely dismissed these days by arguments I don't think are actually very valid. But what doesn't work is trying to slavishly copy the Erlang/Pony style without those considerations.
- vvanders 10y ago
  Considering the production system that the Erlang VM has been deployed to(and the length of time it's existed and thrived) it's hard to make an argument to re-invent it in another language. If that's what your domain space needs, use the BEAM and find a way to talk to it for the parts that you can't move to Erlang.
  - dgfgfdagasdfgfa 10y ago
    It's not hard to justify; that's laughable. It's simple redundancy!

sly010 10y ago

Most of my non trivial goroutines are organized like this: func actor_foo(things) error { set_up_stuff() defer clean_up_stuff() for { select { case msg := <-messages: switch msg.(type) { case *Bla: } case <- other_messages: case <- errors: case <- signals: return nil } } } I recognize there is more to the actor model than just message loops, but I found that an explicit for-select-switch results in better overall readability.

bmurphy1976 10y ago
Is signals your "done" channel?
- sly010 10y ago
  I was just trying to convey an example. I usually "signal" that the parent wants to stop this "actor" for some reason (e.g graceful shutdown). If parent need a "done" channel, it passes it in and "actor" closes it on its way out. Cleanup usually "signals" children and waits for them to be "done". Sometimes "done" is just signalled by the goroutine returning and it is wrapped in parent somehow. But every time I try to formalize it into some "framework" my abstraction fails.
scarnie 10y ago
the only challenge here is that upstream senders will block when your channel(s) are full. This is not inherently bad, but if you have a circular dependency, you can deadlock because queues (channels) are bounded and may fill up. There are solutions to that too, but you have to build that in

stcredzero 10y ago

I'm getting a "Page not Found" from this link.

macintux 10y ago

I've captured a few other open source actor implementations: https://gist.github.com/macintux/6349828#other-actor-implementations https://gist.github.com/macintux/6349828#other-actor-impleme...

RogerAlsing 10y ago

One of the major things will be the tooling around it. As we work with a well defined schema. we can create tools that work for all implementations. e.g. see this CLI tool for managing proto.actor systems live: https://asciinema.org/a/a1b18jiv703e6eog1o2b7domi 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.