[erlang-questions] Erlang and Akka

Thu Aug 28 09:24:17 CEST 2014

The entire availability of Erlang developers is a red herring. FP brings
along its own set of advantages, one major observation is the smaller team
size for the same output in comparison to Java/C++.

Several universities in Europe cover Erlang in their courses. Personally
having taught numerous Erlang/OTP courses in North America and Europe there
are bodies of expertise scattered all over, heck even as far flung as
Vietnam.

Remember when Python first came out ? Folks were complaining about the lack
of braces and how incorrect spaces and tabs can break your code. Absolute
non-issue after a few days of coding.

Erlang syntax is seldom a gotcha, problem areas with Erlang programming is
typically concentrated on understanding recursion and to be honest you can
avoid recursion using the 'lists' module.

The 'if' expression is another problem area [looks like your normal 'if'
doesn't act like your normal 'if'] and I usually tell students to skip that
and use 'case' and if you are using 'case' may as well skip that and write
a function (nod to Garrett Smith).

Regardless if you decide to go with Akka or Erlang there is a learning or
training component for either. The architecture, design and mind-set is
sufficiently different that there is a need to start with a different set
of fundamentals.

On Wed, Aug 27, 2014 at 9:17 PM, Youngkin, Rich <
richard.youngkin@REDACTED> wrote:

> 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
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140828/2a73983a/attachment.htm>