Syvo3

I’ve been following the Coursera course titled “Principles of Reactive Programming” (link), which is almost over (next week will be the last one), and in the last two lessons we learnt how the Akka implementation of actors works.

Now, since in the last four years I have developed code using Erlang for my Ph.D. thesis (and for other secondary projects in between), I am quite used to the actors principles and architecture, but it has been quite interesting to look at them in a different implementation, and I wanted to write a couple of paragraphs on the differences with respect to Erlang, and my (brief) opinion on these differences (beside the fact that Scala is statically typed, which is huuuuuge):

• Akka actors take TONS of syntax from Erlang, in particular: BANG! 🙂
• seeing the messages in Scala as case classes instead of tuples is very very strange at the beginning, and it is even stranger when you assign a message to a variable: it looks like you are calling a function…
• Akka actors have automatic supervision: processes are automatically linked (to use Erlang terminology) to their parents, and a father kills all its children by default when he dies; then you can add specifications on the supervision behavior and tune it better, and as in Erlang you need to explicitly handle the termination messages when needed. Now, this is a characteristic that I am not really sure I really like: I mean, I prefer to decide if I want to spawn a linked process or not, and to decide if I want a process to be supervised or to live by itself. Maybe this is due to the fact that in Erlang supervision works basically when you are using predefined behaviors, while here it works for everyone… I don’t know, I have to try it a little bit more to decide on this
• the receive primitive does not fail if there is no match to a message: this is an improvement on one side, because you can freely ignore some messages that arrive to a process (they are still consumed, see below), but on the other hand you need to remember to implement the function that receives the non-matched messages in your actors, otherwise they will go to the event stream (more on this later), while in Erlang you typically write a case to catch everything else in the end of each receive block, where you log the unforeseen message. Again, mixed feelings: you need to remember stuff, but at the same time you can separate unknown messages and the reaction to them in different blocks of code, which is not bad.
• Akka actors have the concept of context, which basically allows you to change state from time to time and create a sort-of finite state machine for actors behavior; this means that you can divide messages belonging to different phases of the actor in different blocks of code, which helps maintaining everything clearer. I really like this feature.
• Akka has an internal pub-sub system, where actors can publish messages (using topics) and subscribe to topics; this is also the place where everything not catched goes (it is called event stream). It is an interesting concept, and I can imagine it can be quite useful (logging is the first thing that comes to mind).
• Finally, Akka gives developers the possibility of persisting state: I don’t know this characteristic that well, essentially because I have not used it yet (only seen on slides), but it looks interesting and helps overriding the single assignment vs actors with a state…

All in all, I have to say that I like Akka actors, even if I have mixed feelings on a couple of characteristics (especially the automatic supervision, I still have to fully digest it…). Anyway, this is another reason that convinces me that if I had to start a new project from scratch today, I would use Scala for sure.

Read Full Post »