[erlang-questions] Erlang and Akka

[Loïc Hoguin]

On 08/27/2014 12:34 PM, Giovanni Giorgi wrote:
> 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.

A 60 people Erlang team? Just buy Basho or one of the other semi large 
Erlang companies. Done.

On the other hand if you *must* have a 60 people Erlang team *right now* 
I'm not sure what you're building. It's equivalent to needing a team of 
300+ Java developers. I have no idea what kind of project you do with 
that kind of team. :-)

> Erlang immutable state is a big hit in the long run.

I'm not sure what you mean by that?

> On the other way, Java isolation is very strong.  With OSGi frameworks
> you can even run different version of the SAME library side by side. For
> instance, new version of Eclipse can run in "compatibility mode" older
> plugin (with an old API).
> Also if a eclipse plugin crashes, the ide will not crash.
> Also JVM stability is very high.
> For this point of view, IBM has put in Java a lot of its know how about
> its  experience as system-integrator.
> But do not need Java integration capability, Java could be a pain

Erlang has systems that have been running continuously for what, 15 
years? It's nice that Java has some short term stability but it's pretty 
far from what Erlang can achieve.

> Performance: a tricky path
>
> Erlang scheduler is a plus in my opinion because it maximize resource
> usage even if your code is not very optimized: in Java/Ruby/PHP/Python
> this is simply not true and you will need to put a lot of effort to get
> similar performance.

You can write shitty Erlang code, it's just harder because the language 
is a lot smaller and everything is explicit. Performance issues 
generally come from bad architecture decisions instead.

>   About garbage collection: Java is very strong in this area. Also the
> new G1,  a low latency GC works very well:  I use it on my IDEs to
> reduce GUI freeze. Anyway it is still not production ready (at least on
> jdk 1.7 you get core dumps from time to time).

What do you mean reduce GUI freeze? Why is there any freeze to begin 
with? How can you live with that? It's cool that Java tries to improve 
things but it'll never become as good as per process GC.

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

See above.

> I do not know how much erlang is strong in this area so: do an ad hoc
> benchmark on your use cases on raw speed and troughput.

Latency is a lot more important to 95% of applications (including your 
GUI example there, seriously how can you tolerate a freeze?) and Erlang 
is built for latency. You get low latency by default, regardless of the 
number of things happening. That's very powerful. Then you can also get 
throughput although that takes extra work.

> Library availability
>
> Java ecosystem is big. In my opinion too big. If you have the right tool
> in erlang, give a plus to erlang.
> The reason is simple: SpringFramework is very very complex.
> IoC will slow down your developement, and I am not sure will pay its bill.
> So avoid all the hipe around Spring if you do not think you need it.
>
> When I search for erlang clients for some server I use, I find it with
> no problem, so I think Erlang ecosystem is quite mature.

I wouldn't say Erlang has a complete ecosystem although it's getting 
there. On the other hand it doesn't take very long to implement a 
missing library (either by writing it directly or interfacing with C 
code), and while it may sound like wasting your time, the things that 
Erlang makes easy (low latency, distribution, scalability, fault 
tolerance...) make you win a lot more time.

-- 
Loïc Hoguin
http://ninenines.eu