102

I've been looking at akka recently and it's pretty impressive. It looks like it has most of the killer features of erlang - location transparency, supervision hierarchies, and more. Are there any features erlang has that akka doesn't?

ryeguy
  • 65,519
  • 58
  • 198
  • 260
  • Watch this movie about erlang in practice. Too bad there is none about scala http://www.youtube.com/watch?v=G0eBDWigORY – mhstnsc Aug 29 '13 at 08:25

5 Answers5

125

Disclaimer: I am the PO for Akka

  • Erlang does copy-on-send - Akka uses shared memory (immutable objects) for in-VM sends
  • Erlang does per-process GC - Akka uses JVM GCs
  • Erlang has OTP - Akka integrates with the entire Java ecosystem (Apache Camel, JAX-RS, etc etc)
  • Erlang does the process scheduling for you - Akka allows you to use many different Dispatchers with endless configuration opportunities
  • Erlang does hot code reload - Akka can support it, but it's less flexible because of JVM classloading

Those are the ones from the top of my head.

On the other hand, using Akka means that you can use Scala, Java, Groovy or JRuby to write your applications.

om-nom-nom
  • 62,329
  • 13
  • 183
  • 228
Viktor Klang
  • 26,479
  • 7
  • 51
  • 68
  • 39
    Erlang objects are also immutable and the concurrency model does not require copy-on-send within the same node. BEAM for _large_ objects sends a reference. Source: this [SO answer by @rvirdig](http://stackoverflow.com/questions/1798455/concurrency-how-does-shared-memory-vs-message-passing-handle-large-data-structu/1801214#1801214). – FooF May 19 '12 at 13:29
  • Of course the concurrency model doesn't require it, it just needs to follow the same contract, i.e. that the messages are observably immutable. Which you guarantee for mutable and remote ones by copy-on-send. – Viktor Klang May 19 '12 at 13:45
  • 26
    Erlang does copy-on-send to make GC more efficient -- it can work in per process basis. This is why there are no huge GC pauses in Erlang apps as opposed to JVM/Akka apps. – andreypopp May 28 '12 at 05:35
  • 4
    Well, Andrey, that sort of depends on which JVM / GC you're using. http://www.azulsystems.com/products/zing/whatisit – Viktor Klang May 28 '12 at 12:10
  • Usually I don't refer to bechmarks much because they are wage but [Benchmarks](http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchmarks) show the copy-on-send can be slow – MaX May 31 '12 at 18:20
  • 1
    It's a pity this question has been closed since one of the most important differences - the fundamentally different semantics of an actor's (Scala) message dispatch semantics to Erlang message matching - has not been mentioned. A comment is too limited to cover this. – johanneslink May 06 '13 at 17:23
  • 5
    Erlang has a reduction number for each process, even you are in a busy heavy computation loop, Erlang VM can pause the process and let other hungry processes to take more CPU cycles. That's a very important feature that JVM doesnot provide. – Daniel Jun 04 '15 at 02:57
  • 6
    @MaX Erlang is often 5x slower than Java because lack of JIT support. But Erlang has no GC pause, it's designed for concurrency and 7*24 telecom applications, Erlang concerns more about process fairness, avoiding starvation and deadlock, it is not designed for throughput like JVM. So, it's really orange and apple. – Daniel Jun 04 '15 at 03:01
  • 2
    Having separate process heaps and copy-on-send **scales**! – rvirding Sep 26 '15 at 20:17
  • 1
    Knowing both environments I can't help but notice this answer doesn't really expose Akkas weaknesses and may be misleading. The most important weakness in my opinion is that the support for the concept error kernels is weak at best in Akka primarily due to the JVM ecosystem with shared memory and lack of proper isolation. Erlang may not be perfect either but it is quite literally light years ahead. – Eric des Courtis Oct 26 '16 at 18:44
  • 1
    @EricdesCourtis "Local" isolation is definitely better in Erlang, BUT a single NIF-call can crash the Erlang VM, and for resilience you need multiple physical nodes as well. (I am a fan of both Akka and Erlang) – Viktor Klang Oct 28 '16 at 12:07
  • 1
    @ViktorKlang While that is definitely true and actually the NIF is the least of our worries since we are running on a mountain of C code underneath (kernel + erlang vm itself). I think we can agree that most NIFs are tiny and that kernel and the erlang vm itself are well tested in general (by brute force). The JVM ecosystem is worst in practice in my opinion because so much of it doesn't support the idea of an error kernel as a core concept. At least Erlang NIF developers know to keep the error kernel minimal. – Eric des Courtis Oct 28 '16 at 18:50
  • 1
    @EricdesCourtis No, i don't mean BIFs, I mean NIFs, so if anyone creates or calls possibly sigsegving custom C code then process isolation is violated. What we've seen with Akka and mandatory parental supervision is that it allows for very robust JVM-based systems. – Viktor Klang Oct 28 '16 at 21:44
  • 1
    @ViktorKlang The same can be said for the JVM with JNI. I think having shared memory and locks is a far more serious problem in practice than NIFs. – Eric des Courtis Oct 28 '16 at 22:50
  • 1
    @EricdesCourtis My point is that the isolation on a single node in Erlang is definitely not bulletproof. And w.r.t. lcocs and *mutable state* concurrency control, you don't need to convince me. Shared immutable state though is extremely benign and convenient. – Viktor Klang Oct 28 '16 at 23:32
  • 1
    @ViktorKlang Bullet proof enough. After all we still have to deal with hardware failure. – Eric des Courtis Oct 29 '16 at 14:14
  • PO - project operator? – Alexander Mills Feb 08 '19 at 03:03
  • @AlexanderMills product owner, I think (though Viktor would now be Akka Team Lead emeritus) – Levi Ramsey Feb 04 '21 at 20:33
78

In Erlang processes are guaranteed to be switched approximately each 1000 reductions. In such a naive framework as Scala/Akka agent owns a scheduler until it finishes work in receive. Checkmate. Game over. Hasta la vista:) People, do not waste your time on pseudo techs. I shocked that guys here compare Scala with Erlang.

Also there are many other so called "killer features", but here is my advice, do not think in terms of features, think about idioms that enables particular language. Scala steals "best features", Erlang enables/implements you with right idioms to build systems reliably, with high level language that driven from those right idioms. When you learn Erlang you are rebuilding your mind, your way of thinking about distributed reliable system, Erlang teaches you and upgrades you. Scala is just another one imperative (oh, sorry, multiparadigmal, funny word) language that tries to steal good features from other languages.

Andrei Dziahel
  • 969
  • 5
  • 14
vjache
  • 1,021
  • 7
  • 2
  • 10
    Erlang way of making all IO implicitly asynchronous is very elegant. Async IO can done using NIO APIs in Scala, which doesn't look like check-mate to me, but a less elegant solution. – HRJ Sep 07 '11 at 15:16
  • 8
    what in the hell are you talking about?! how is processing 1000 straight tasks better than a roundrobin scheduling, or even near a smallestmailbox scheduling!! – FUD Mar 28 '13 at 04:23
  • 8
    @vjache - I agree. My many years as a java programmer has taught me that you will at some point have to investigate the layer below you. Scala/Akka seems to be just another layer on top of lots of other layers (Eg. nio, netty, etc), all of which you will need to understand at some point. Even though I've only just started working with Erlang, it looks like I will have fewer layers that I need to understand to get the job done. Distributed programming in Erlang feels much lighter weight to Scala/Akka, probably in a similar way that python was the lighter alternative to java for web apps. – Chris Snow Nov 30 '13 at 13:42
  • @FUD: maybe he meant 1000 Erlang instructions? he couldn't have meant 1000 messages... – Erik Kaplun Mar 05 '14 at 02:19
  • 2
    @ErikAllik He meant 1000 "reductions". Think of a reduction as a token to execute a bit of code (it's not, but it does the job for explaining...). After 1000 reductions, the scheduler switches to a different process. More infos at http://erlang.org/pipermail/erlang-questions/2001-April/003132.html – Aegis Aug 28 '14 at 14:09
  • @HRJ, +1. When you work with Akka, you still think about blocking I/O, and try to avoid it with some patterns (Future), it makes no difference from programming with threads. Implicitly async IO is a huge differentiator, both Erlang and Go provide it at language level, which Scala Akka does not. I truly feel Akka is not a real actor model. – Dagang Nov 07 '15 at 23:22
  • When we are talking about GC, it more sounds like we are comparing functional programming language with none functional programming language. And when we do comparing two languages, usually we are comparing language itself without thinking about the 'context' where you are going to use it. – Joshua May 26 '16 at 09:10
  • what do you mean by every 1000 "reductions"? – Alexander Mills Feb 08 '19 at 03:06
  • Is all I/O in Erlang async by default (just like in Golang)? – Alexander Mills Feb 08 '19 at 03:09
  • This is such a good and honestly profound comment that it's one of the only ones on the site I keep coming back to a decade later. "Checmate, game over, hasta la vista" ;-) I've used that not too seldom, since! The idea that an axiomatic idiom is defined, and you build on that, as opposed to cooking a 4-seaons pizza with all extra toppings that you don't know what it is anymore. explains the difference perfectly. – Thomas Browne May 05 '22 at 23:38
40

Nearly nobody mentions process isolation. Without guarantees of "your thread cannot mess with my junk", distributed systems are much more difficult to reason about. (They're already difficult enough with Erlang's processes.)

AFAIK (which isn't far, given my limited direct experience with the JVM), only Erlang actually gets process isolation "right" on the JVM. Mr. Google can give some hints on where to find research by Fox and Candea (?) on research systems that use a "micro-reboot" technique ("recovery-oriented computing"). An Erlang developer reads that research and says a couple of things:

  1. Welcome to the club, what took you so long?
  2. The JVM makes it awfully, awfully hard to join, though. :-)
mr.b
  • 4,932
  • 11
  • 38
  • 55
Scott Lystig Fritchie
  • 769
  • 5
  • 4
14

For me, hot code swapping in an entire Erlang cluster without downtime (for example: make:all([netload]) is one of the Erlang killer features.

But let's reverse your question: What does akka have that Erlang doesn't? Of course you can add dozens of extensions and libraries (scala, akka, spring, osgi, ...) to Java to try to come close to Erlang. But where is the point? In sum all these extensions are much more complex than learning the simple Erlang language that now has proven for over 2 decades that it can do the job offering top scalability with zero downtime.

Rumpelstilz
  • 267
  • 2
  • 7
  • 31
    IMO, Scala is a much better language on the syntax level than Erlang. It has objects, traits, proper namespaces, proper type safety, no ugly record syntax, etc. The community is larger, I can use all available Java tools and it just feels more polished. – ryeguy Dec 20 '10 at 16:59
  • 17
    @ryeguy: "better language on the syntax level" ... hmm, define "better" for "syntax". When I compare languages syntax is the most irrelevant factor (because it is only a matter of taste or to what you are used). – Peer Stritzinger Dec 20 '10 at 20:00
  • 5
    @ryeguy Different semantics, different syntax. – rvirding Dec 20 '10 at 21:37
  • 3
    hot code swapping becomes a pain if you need to maintain state between different code versions, in the end it's easier to shutdown the process and migrate state on startup – OlegYch Oct 18 '13 at 11:19
  • 4
    @ryeguy The syntax of a programming language is next to irrelevant; what matters are its semantics. Erlang is a functional PL so of course it doesn't have objects. Traits, type safety etc are due to Scala being a strongly typed language, while Erlang is dynamically typed; that's a design choice. Nevertheless, I would invite you to take a look at Elixir if you want the benefits of Erlang with a more modern feel ;) – Aegis Aug 28 '14 at 14:12
6

Probably Erlang is better for bigger distributed systems (following vjache's answer) but for a normal server when you just want use the full power of multiple CPUs then Akka is good choice— provides good abstraction, performance and integration with the Java ecosystem.

Erik Kaplun
  • 37,128
  • 15
  • 99
  • 111
kodstark
  • 463
  • 4
  • 11