<div dir="ltr">Hi again,<div><br></div><div>Thanks for all the responses, they're very helpful. Thanks to Leonard for the linkedIn discussion tip (<a href="https://www.linkedin.com/groups/Erlang-OTP-seem-be-getting-90878.S.182039556" style="white-space:pre-wrap">https://www.linkedin.com/groups/Erlang-OTP-seem-be-getting-90878.S.182039556</a>).  Despite a brief descent into a rambling flame post it's worth reading.</div>
<div><br></div><div>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.</div><div><br></div><div>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).<br>
</div><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><div>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.</div>
<div><br></div><div>Thanks again for all the comments, keep them coming if you're so inclined. I've found all of them useful.</div><div><br></div><div>Cheers,</div><div>Rich</div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">
On 27 Aug 2014, at 11:34, Giovanni Giorgi <<img border="0" src="http://erlang.org/pipermail/erlang-questions/emailaddrs/ema-6521.png">> wrote:

><i> 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.
</i>><i> 
</i>><i> Anyway the questions I will do to myself will be: 
</i>><i> 
</i>><i> Team know-how
</i>><i> 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.
</i>><i> 
</i>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.

><i> Erlang immutable state is a big hit in the long run.
</i>><i> 
</i>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. ;-)
><i> On the other way, Java isolation is very strong.
</i>><i> 
</i>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.

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

><i> 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.
</i>><i> 
</i>><i> With very huge heaps (hundres of GBs) you can have problems, and Red Hat is pushing a new implementation to ovrecome this.
</i>><i> 
</i>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.
<a href="http://feuerlabs.com/">http://feuerlabs.com</a>
</pre></div><div><br></div></div>