
The Road to Akka.NET v1.0 - numo16
http://petabridge.com/blog/akkadotnet-road-to-v1/
======
rdtsc
Looks impressive. Great work! Very well done site as well.

Coming from Erlang, and familiar with a few basic actor concepts (but not with
Scala's Akka terminology), I see a lot of new things and it seems a bit
daunting.

I started browsing documentation and looked at:

[http://getakka.net/wiki/Addressing](http://getakka.net/wiki/Addressing)

And see new things like:

    
    
       ActorRef, 
       ^ActorOf, 
       ^ActorSelection, 
       DeadLetterActorRef, 
       EmptyLocalActorRef, 
       ActorCell, 
       ActorPath (physical and logical). 
       A URI spec that for "akka://"  
    

From an outsider point of view who knows about sending a message to a process
ID which looks like "Pid ! Message" in Erlang, what is the overall philosophy
of needing those other concepts. Is it because of static typing, trying to
provide global discovery or registration mechanisms?

~~~
skotzko
Great question, thanks for asking it. We'll also be reworking the docs on the
way to 1.0 to make a lot of this much clearer.

The short answer is that these things enable various nice features of the
framework, like automatically scaling out your actors, safely managing actor
restarts, and managing message delivery for you.

Just to cover a few of those briefly:

 __ _What is an ActorRef?_ __

An ActorRef is a reference or handle to an actor. The purpose of an ActorRef
is to support sending messages to an actor through the ActorSystem. You never
talk directly to an actor—you send messages to its ActorRef and the
ActorSystem takes care of delivering those messages for you.

 __ _What are Props?_ __

Think of Props as a recipe for making an actor. Technically, Props is a
configuration class that encapsulates all the information needed to make an
instance of a given type of actor.

One of the reasons Props encapsulate the entire recipe for making an actor
(including deployment info) is so the system can manage restarts/lifecycle
safely. It also can be serialized so that you can remotely deploy actors to
other machines in a cluster -- BUT, this is invisible to you (location
transparency, AKA you don't care if your actors are all in one process or on
10 machines spread around the planet).

 __ _What is an ActorPath?_ __

Actor path == actor position in hierarchy.

Actors form intrinsic supervision hierarchies. This means there are "top
level" actors, which essentially report directly to the ActorSystem itself,
and there are "child" actors, which report to other actors.

Every actor in this hierarchy has an address. To send a message from one actor
to another, you just have to know it's address (AKA its "ActorPath"). This is
what a full actor address looks like:
akka.tcp://MyActorSystem@localhost:9001/user/a1/b2.

 __ _What is ActorSelection?_ __

This is using the actor path to get an ActorRef (handle to an actor). So
instead of getting a handle to an actor by creating it, you 're "looking up"
the handle by its address. Kind of like looking up someone on Skype by their
username.

####

You may find this post interesting to go in depth on actor hierarchies / paths
/ supervision: [http://petabridge.com/blog/how-actors-recover-from-
failure-h...](http://petabridge.com/blog/how-actors-recover-from-failure-
hierarchy-and-supervision/)

Also, if you're interested in learning Akka.NET, we're launching a free, self-
paced bootcamp this Saturday. Details are here:
[http://learnakka.net](http://learnakka.net)

Hope this helps.

~~~
rdtsc
Thank you explaining! I understand it better now. This comment would make a
great doc entry.

It looks like ActorRef is equivalent to Erlang's process ID's (PIDs). As there
a message is sent to an actor's PID.

Props sound very powerful. I like the idea. With Erlang one can do it but with
extra work. With live code-reloading and access to the module loader.

Do Actor hierarchies imply a global registration mechanism. If it does,
wondering what kind of consistency/availability trade-offs it makes. Erlang's
clusters do not handle network partitions too well sometimes and there are few
custom registration/leader-election libraries for it. (locks, gproc, pg2)

~~~
Aaronontheweb
> Do Actor hierarchies imply a global registration mechanism?

No, all registration is done locally underneath the parent actor - i.e. if one
parent creates three children, the only place where that state is registered
is the parent itself. The root actor on each node can quickly figure out by
traversing the tree whether or not a child at a given path exists or not.

The only exception to this convention are remote-deployed actors - if
ActorSystem A deploys an actor remotely onto ActorSystem B, the RemoteDaemon
(a system-level actor) keeps a record of who has actors deployed onto each
other. That way if ActorSystem B dies (crash, network goes down, etc...)
ActorSystem A can notify all of the local actors who depended on remote-
deployed actors that those actors are effectively dead.

------
moomin
If you work in this space, you owe it to yourself to check out the Retlang
library. Comprehensible model, blindingly fast, worked since .NET 2 and...
utterly unmarketed.

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

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

------
smhinsey
What are people's production experiences with this? I've written half baked
implementations of so many of these ideas that I'd love to not have to own any
longer.

~~~
hhandoko
I'm taking a cautious approach (as with any new libraries), but so far it's
been in a couple of small projects in production and working well.

It is certainly far easier to write new implementations with Akka.NET in mind.
But there are a couple of strategies that I found useful in retrofit
scenarios:

1) Use adapter / proxy patterns (with DI / IoC). A bit tedious, but easy to
back away from.

2) Use async more. It does force you to adopt a certain mental model, which
helps make the transition to Akka a bit easier (rather than returning
Task<T>.Result everywhere from Akka actors).

