[erlang-questions] Erlang and Akka

[Ulf Wiger]

On 27 Aug 2014, at 11:34, Giovanni Giorgi <jj@REDACTED> wrote:

> Hi, I am working in Java (I am a 15 years old java Consultant by the way) and in my humble opinion comparing Akka and Erlang is like comparing apple and oranges.
> 
> Anyway the questions I will do to myself will be: 
> 
> Team know-how
> For instance if I must set up a 60 pepole team, where can I find the guys easier? Using Akka or Erlang? I do not think there are a very large base of Akka experts out of there.
> 
As others have pointed out, 60 people is a *huge* team for an Erlang project. I doubt you need that many unless you’re building a monster of an app. The AXD 301 team had roughly that many Erlang programmers for almost 2 million lines of Erlang code; arguably, it was too many people, but the list of requirements was really what drove the size of the project. Basically, look at how many people are needed to wrap their collective heads around the functional requirements. Those guys should all be programming, and you’re not likely to need many more programmers than that.

> Erlang immutable state is a big hit in the long run.
> 
On the contrary. The long run is where immutability pays off, mainly in two ways:

- Software quality: Immutability basically goes together with referential transparency, and you should aim to write as many functions as possible in a side-effect free way. Once such a function has been debugged and works correctly, it *stays* correct, until the requirements change. For this reason, legacy Erlang code can truly become rock-solid.

- Performance. It may sound weird, but immutability and acyclic data structures really help the memory management subsystem as well as simplify scaling across multiple cores. The area where it hurts is mostly core that has to sequentially run through large data sets, flipping bits or making other small modifications along the way - the Dijkstra Shortest Path First algorithm comes to mind. But if you’re building a complex system with lots of concurrency, immutability will keep you sane and help your applications scale. Performance losses in this class of systems, using conventional coding techniques, are often due to code complexity as much as anything else: you lose the ability to reason about how the code behaves, and all those fancy tricks that can help performance in smaller systems will only make things worse.

But of course it depends on what kind of system you’re building. Erlang is very performant for the kinds of system that it was designed for. There are lots of stories about Erlang-based systems handling outright crazy loads compared to the competition.

The Java story is not particularly good when it comes to multicore. You really have to know what you’re doing, or have a problem that is embarrassingly parallel. The main multicore problem in Erlang is that it’s hard to come by as many cores as you think you can utilize. ;-)
> On the other way, Java isolation is very strong.
> 
Actually, not compared to Erlang. The reason is shared (mutable) objects. If a thread crashes that shares data with other threads, you are basically lost.

Since Erlang uses share-nothing concurrency with copying message passing, a dead process really doesn’t hurt the data of other processes, and can simply be swept away by the GC.

> Also JVM stability is very high.
> 
Granted. So is the stability of the Erlang VM.

> Remember "old HotSpot GC" is very powerful out of the box: a 1GB RAM app server can be tuned easily to avoid full GC /for days/, because increment GC are "just fine" for the day by day processing.
> 
> With very huge heaps (hundres of GBs) you can have problems, and Red Hat is pushing a new implementation to ovrecome this.
> 
If you just measure the amount of manpower that has gone into Java GC, it should be far superior to the Erlang GC, but GC is a much, much harder problem in Java than it is in Erlang.

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140827/d1243cc6/attachment.htm>