How does akka compare to Erlang?

Question

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?

Solution 1

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.

Solution 2

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.

Solution 3

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. :-)

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[ryeguy]

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.

[Peer Stritzinger]

@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).

[rvirding]

@ryeguy Different semantics, different syntax.

[FooF]

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.

[Viktor Klang]

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.

[andreypopp]

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.

[Viktor Klang]

Well, Andrey, that sort of depends on which JVM / GC you're using. azulsystems.com/products/zing/whatisit

[MaX]

Usually I don't refer to bechmarks much because they are wage but Benchmarks show the copy-on-send can be slow

[johanneslink]

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.

[OlegYch]

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

[Aegis]

@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 ;)

[Daniel]

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]

@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.

[rvirding]

Having separate process heaps and copy-on-send scales!

[Viktor Klang]

Process isolation is indeed super nice. However, even Erlang isn't immune to a NIF gone awry.

[Eric des Courtis]

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.

[Viktor Klang]

@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)

[Eric des Courtis]

@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.

[Viktor Klang]

@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.

[Eric des Courtis]

@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.

[Viktor Klang]

@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.

[Eric des Courtis]

@ViktorKlang Bullet proof enough. After all we still have to deal with hardware failure.