Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Erlang and Akka Actors–A Story of Tradeoffs

Erlang and Akka Actors–A Story of Tradeoffs



Pranav Rao discusses how BEAM differs from Akka actors implemented over the JVM and how design decisions can affect performance.


Pranav Rao has worked in and Amazon across a host of languages and problem domains. He has written critical Ruby/Rails services during's explosive growth and later managed a team of Elixir/Erlang devs and built a real-time analytics pipeline on top of MQTT. At Amazon he’s currently working on big data applications running on a Spark + ElasticSearch cluster.

About the conference

The Erlang Factory Lite conferences have been evolving for the past few years. The origins were about bringing together developers to spread the Erlang love and to share battle stories. Over the years our community has grown beyond Erlang to encompass a more diverse range of languages from the Erlang Ecosystem.

Recorded at:

Mar 16, 2018

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Is the comparison really fair?

    by Nirmalya Sengupta,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Very informative talk! It is obvious that Pranav has spent considerable time studying these sort of applications.
    However, it is not really fair to compare Erlang and Akka. Erlang has the advantage of having its own runtime engine. Akka has to piggyback JVM's threading infrastructure. Pre-emptive multitasking is - at the end of the day - OS's prerogative. If a runtime is overtaking this responsibility, it is that runtime's decision. The question that someone from the audience asked at the very end of the session, is quite valid. The answer was unclear from we saw in the video, if at all given.

    For modelling Dining Philosopher's problem, a FSM - irrespective of the language used to implement it - is an obvious direction to take. Any other form, is an exercise in delaying the inevitable! :-)

    Having said this, I must say that I have learnt a few things from this presentation. Thanks, Mr. Pranav Rao.

  • Interesting topic. I also gave a talk about this and have something to say :)

    by Agustín Ramos,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Nice to see people are interested in this topic. I myself talked about this last November (2017) though my conclusions were a little bit different. Here are the slides of the talk if you are interested My conclusion is more or less the following: Akka is not a good implementation of the actor model, mainly because the runtime (the JVM) doesn't support it adequately. It's very complex to get a system working properly in Akka compared to Erlang/Elixir, and it's very easy to shoot your own foot, because the runtime doesn't natively provide characteristics for programmers to think in terms of actors. So, when you use Akka, you not only think in terms of actors, but you have to think a lot in the underlying concurrent machinery of the JVM and how it relates to your actors. In the end, this is a burden. You could add that the tooling and development cycles provided by those tools, is an additional reason to just drop Akka (particularly if you use Scala at the same time). I wouldn't recommend Akka to Java developers wanting to implement highly concurrent and fault tolerant systems, just go for Erlang/Elixir. If you are afraid of such a change in platform, I'd would rather recommend other frameworks, vert.x being the one that provides unobtrusive and really helpful mechanisms to create soft real time and highly concurrent systems on top of the JVM.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p