What is difference between FSharp.Actor and AKKA? when to choose which ?

[Kunjan Dalal]

In near past two wonderful work come to surface from the actor side. Can any one describe which is doing what, so it will be easy for end user to make decision on that basis. I am sure both are wonderful library. As, I am following AKKA (scala one) and FSharp.Actor from quite a long time. 

Please let me know if any further explanation required.  

[Don Syme]

 

Hi Kunjan,

 

Indeed there are now three significant actor frameworks to compare J

 

-          Orleans

-          Akka.NET

-          FSharp.Actor

 

as well as the in-memory agent actors that F# already has.

 

There is an interesting comparison of Orleans and Akka here.

 

Cheers!

Don

--
--
To post, send email to fsharp-o...@googlegroups.com
To unsubscribe, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource
---
You received this message because you are subscribed to the Google Groups "F# Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Bull]

Hi, 

They are both tackling the same problem. From similar angles. Orleans takes a slightly different approach to actors and is well explained in the article don points to.

With regards to Akka and FSharp.Actor, I would say Akka is FSharp.Actor's heavier-weight cousin. Akka provides an lot of functionality and is very opinionated about how it goes about implementing this functionality, this is good as it doesn't let you shoot yourself in the foot. On the flip side FSharp.Actor is lighter-weight and assumes nothing about how you wish to manage your actors and provides a collection of simple interfaces that allow you to customize and bend the framework however you want, along with a key set of Primitives like simple routing, supervision and remoting.

Hope this helps 

Colin

[Paulmichael Blasucci]

Hi all,

I'd just like to draw attention to a peripherally-related technology: ZeroMQ. Don't be fooled be the name! It's not message-queuing middle-ware (a la MSMQ, RabbitMQ, et cetera).  It addresses the issue of distributed computing via message-passing (ie: zero-shared-state actors). It is quite mature and, in addition to being extremely fast and flexible, has the benefit of enabling properly polyglot designs. It has excellent cross-platform support, solid documentation, and a thriving open-source community. While it may seem more low-level than some of the other technologies listed on this thread, it's quite easy to get started with ZeroMQ. I've personally used it in a variety of scenarios (chat systems, real-time trading, job scheduling systems, a direct replacement for WCF, and much more). It has an F# binding (fszmq) and a pure-managed port (netmq). Please feel free to ping me if you want more information.

Cheers!

Paulmichael

[Eugen Hotwagner]

Hi,

Also rx reactive https://rx.codeplex.com/ is another message passing technology. 

There is also a nice fsharp wrapper: https://github.com/fsprojects/FSharp.Reactive

--

[Colin Bull]

Hi Paul,

 

I have actually been playing with your library and using it as an underlying transport for Fshapr.actor, aswell as Fracture and some other libraries I haven't quiet the full remoting story down in FSharp.Actor yet, but when I do I definitely intend on adding zmq as a transport

 

Cheers

[Anton Tayanovskyy]

Sorry for being slightly off-topic, but I would like to share
something I wish I discovered before: CML/Hopac.

There are a couple of related but distinct concerns actor libraries
try to solve:

* concurrency
* fault tolerance
* distribution

From my limited experience, if you are doing just concurrency + fault
tolerance in a single address space, Actors are a pretty bad way to
structure code for anything non-trivial. Concurrent ML seems to be
*much* more suited for this task due to its added flexibility. There
is now an F# library [1], thanks to Vesa Karvonen, that provides an
interface close to CML, with synchronous channels, selective
communication and nack's; it also provides a few baked-in
synchronization primitives (ivar, mvar, variations of locks). The
implementation is pretty good (performant), though tuned for gaming
rather than server apps at this point. I have a system I have written
in Actor style that caused multiple days of headaches, and today I
realize a lot of the things I was trying are trivial with CML. I wish
Hopac was available when I was writing it.

I have not programmed any complicated distributed systems or systems
with high demands for fault tolerance. Perhaps Actor style of
programming is necessary for those. Still, I think writers of Actor
libraries could benefit greatly from having CML combinators available,
especially at prototyping stage, as opposed to starting from bare F#
stdlib. Many patterns are easily expressed in CML, but can be
implemented with more performance by specializing code and using locks
or Interlocked.* patterns. So it sounds productive to prototype in
CML and rewrite performance-critical parts when design is ready.

I also saw Joinads extension for F# mentioned but have not tried
working with those. At a glance, it seems that Join calculus / joinads
should have the same benefits as CML. Not sure which is more
expressive, Joinads or CML, but both should be more expressive than
basic actors as in F# stdlib (MailboxProcessor). Perhaps Tomas can
comment on this.

[1]: https://github.com/VesaKarvonen/Hopac

Thanks,

--A