[erlang-questions] Erlang and Akka

[Youngkin, Rich]

Hi again,

Thanks for all the responses, they're very helpful. Thanks to Leonard for
the linkedIn discussion tip (
https://www.linkedin.com/groups/Erlang-OTP-seem-be-getting-90878.S.182039556).
 Despite a brief descent into a rambling flame post it's worth reading.

I'm still trying to wrap my head around many of the comments given that my
Akka knowledge is only marginally better than knowing nothing about Akka.

One comment that resonated with me is the need to choose the proper tool.
My sense is (and was) that both Erlang and Akka can be used effectively to
solve similar problems. The need to fit into the JVM ecosystem is one item
that might tilt one towards Akka. For other reasons the JVM might tilt one
towards Erlang (along other things like immutability and conciseness).

To answer a question in Loic's original response, why did I raise this
question?  See below for that, but I intentionally left the question
open-ended in order to get the wider range of responses.

One of the reasons I raised the question is an argument I often hear
regarding the availability of skilled Erlang developers.  While I think
this is generally a valid argument, I think it starts to become less of an
issue when the value of a functional approach using OTP-like capabilities
becomes important.  IMO, the conceptual complexity of these 2 areas far
outweigh the cost of getting up to speed with Erlang syntax.  In this
respect I think Erlang and Akka, at least Akka/Scala, will be fairly
similar in their learning curves. Any comments?

Another reason I raised the question is that we're currently considering
refactoring our fairly monolithic Erlang app into a set of smaller, more
focused, services. This raised the previous question about the availability
of skilled Erlang developers. In pursuing this refactoring there's no
reason to chose any single technology for the entire set of new services.
So, the best tool for the job is very reasonable, keeping in mind that
there's an existing Erlang code base that mostly works pretty well.

Thanks again for all the comments, keep them coming if you're so inclined.
I've found all of them useful.

Cheers,
Rich

On 27 Aug 2014, at 11:34, Giovanni Giorgi <> 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/d7dfd09e/attachment.htm>