[erlang-questions] Best actor libraries in other languages?

[Tim Watson]

On 13 Feb 2013, at 07:41, Joe Armstrong wrote:
> On Wed, Feb 13, 2013 at 1:42 AM, Toby Thain <toby@REDACTED> wrote:
> On 11/02/13 10:09 AM, Andrew Pennebaker wrote:
> Of course Erlang has a killer actors library as a core component of
> itself. Sadly, Erlang is not always an option (e.g., customer requires a
> JVM language). Which actor libraries in other languages come close to
> Erlang's in terms of:
> 
> * Syntax conciseness (spawn, !, receive)
> * Polymorphism (receiving different kinds of messages)
> * Fault-tolerance (GC per actor, actor crash doesn't crash the system)
> 
> Akka and Scala specifically offer all the above.
> 

As does Cloud Haskell, as well as selective receive and matching/condition-based receive clauses, timeouts, etc. I suspect Akka/Scala do as well, but I haven't looked.

> Plus the actor model does not address problems of fault propagation.
> 

Indeed! It is exactly why Erlang shines so much - it's the Erlang model that Cloud Haskell explicitly follows, not the Actor model. In fact, our general motto is "do what Erlang does".

> The statement "X has Erlang like semantics" usually means "X has Erlang like semantics
> <emph>except for error handling</emph>" - handling errors out-of-band is a big win.
> 
> Isolation is the key property that must be guaranteed for actors. If <<I>> can crash
> <<your>> code then all bets are off.
> 

That is why Cloud Haskell was built to follow the "Unified Semantics for Future Erlang" paper (Svensson et al.) - send is async, process failures are completely isolated and only propagated via links (or signalled via monitors), trapping of exit signals is structured/scoped, etc. It is basically a homage to Erlang, rather than 'we can do actors/distribution too....'

It is, of course, quite incomplete as it stands and there are various decisions that have been deferred until later. Not to mention the fact that Haskell has a very strict type system, so programming Cloud Haskell is a very different experience to programming Erlang - and there's no hot-upgrades or anything like that.

The formal semantics are available at http://haskell-distributed.github.com/static/semantics.pdf - any feedback about the implementation or conceptual approach will be gratefully received!!! :)

Of course, I spend my days programming Erlang, so hopefully (at night!) I'm bringing an Erlang-ish mindset to the Cloud Haskell project. One of these days I'm going to get around to writing a network-transport backend that Cloud Haskell nodes can use to speak the Erlang distribution protocol: Then we'll have H-Nodes as well as C-nodes/jinterface/pyinterface/etc. Someone has already done a bit of that work, but it's quite old and bit-rotten.

Cheers,
Tim

> /Joe 
> 
> 
> 
> 
>  
> 
> 
> * Live updates (different code versions up at the same time, hot code
> updates)
> 
> This can be done on the JVM, as I understand it (JRebel etc) but I can't speak from experience. Certainly it's not as designed-in and natural as Erlang.
> 
> --Toby
> 
> 
> 
> Does Scala and/or Akka offer anything like these features? What about
> Ruby's Celluloid? What are the best actor libraries in Common Lisp and
> Scheme?
> 
> The Haskell community seems to prefer STM over actors. How does the
> Erlang community feel about STM?
> 
> --
> Cheers,
> 
> Andrew Pennebaker
> www.yellosoft.us <http://www.yellosoft.us>
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions