
Proto Actor – Fast distributed actors for Golang and C# - cube2222
http://proto.actor
======
KirinDave
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
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.

~~~
vvanders
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
It's not hard to justify; that's laughable. It's simple redundancy!

~~~
techdragon
Sometimes the concurrency benefits just don't add up when compared to other
business/project concerns.

I say this as an big fan of Erlang, truth is, sometimes you just have to
accept that your job is to write a python/Django backend without a line of
JavaScript in order to serve as a line of business app, and if the load gets
bigger, you just throw another server at it.

That said, erlang is great, elixir is awesome, and both are 100% worth _every_
developers time to learn.

~~~
dgfgfdagasdfgfa
I'm not sure where concurrency plays into this at all.

------
partisan
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)

~~~
hudo
And im getting bunch of 404s for .net docs. Which means its not really a
serious project

~~~
protomyth
Tried to click on the "Books" link and got a 404. I get the feeling they
really aren't ready for visitors yet.

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

~~~
Matthias247
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.

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

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

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

~~~
RogerAlsing
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
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
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...](https://rogerjohansson.blog/2016/03/13/random-things-learned-
building-akka-net-part-1/)

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"

------
sly010
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
Is signals your "done" channel?

~~~
sly010
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.

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

