

Erlang and Akka - rdtsc
http://erlang.org/pipermail/erlang-questions/2014-August/080717.html

======
easytiger
Applies in any language. If the non trivial problem is well defined and you
solve it, using a distributed computing pattern, e.g. lots of c++ process
communicating over a specific transport (say zeromq) using a unified object
description (say protobuf) then you get pretty close to this exact same
promise. That's essentially how most erlang solutions feel to me at least.

Am i missing something?

~~~
rdtsc
You are not, very good observation. I am doing the same with Python. Except in
Erlang you can have a lot more processes and distribution & serialization is
built it + many other diagnostic and debugging tools.

The point about function idempotent and minimization of state made by Ulf
Wiger is also important I think. Being able to test a function will all the
inputs and then say, well it works and this part is done. While if it is a
method attached to a large object you might not be able to easily do that
without lots of mocks. This of course applies to any language too not just
Erlang.

~~~
easytiger
Yes, i see your point. I did read the Armstong book many years ago and played
with erlang and was blown over by its feature set.

This definitely bled into some of my current work along with the zeromq book
by Pieter Hintjens. This led me to my current work where i fully reimplemented
a couple of existing commercial solutions my client had purchased for
$millions in licensing fees and simply boiled it down in to a series of steps
which were then implemented in single threaded processes (except for one!) in
python communicating as above. With almost no magic the throughput and
timliness of the data increased 10 fold. Then these processes were
individually rewritten in c++ & one particular one in java and the throughput
increased massively again.

My point being this whole divide and conquer thing is totally legit :)

------
bfrog
Does Akka solve the periodic GC pause of the JVM in some magical way? If not
then to me it seems like a tough sell. Maybe I have 100K Akka actors with
active client connections, now suddenly there's a GC Pause of a few seconds. I
seriously wonder if will just result in a trainwreck of the JVM crashing. I've
seen the JVM crash enough times to know its not by any means bulletproof.

------
CmonDev
"...until the requirements change..." \- nothing to do with Erlang per se.
Let's move on.

~~~
rdtsc
It has to do with Erlang. Because the original discussion point to 2 things in
Erlang that make it easier -- immutability of data structures and the
functional aspect. Testing a function that idempotent means that when it is
tested it will be solid the only work you'd have to do is if requirement
changes. In OO programming having large objects with mutable state + threads,
it is very hard to reason how a particular (failure) state was arrived it. So
besides requirements change another thing that changes is the state in the
objects (in an unpredictable and untraceable). You end up with engineers
saying things like "Yeah I see this bad data in this property, but how the
hell did it get this, I don't know".

~~~
CmonDev
Ok, maybe the problem is that I am already avoiding the large objects, mutable
state and threads in my mainstream OOP language code. I am also applying the
idempotence where applicable.

