Also Erlang use multiple threads of execution to good effect to monitor and recover from failures
(see Error Handling in http://ferd.ca/an-open-letter-to-the-erlang-beginner-or-onlooker.html)

Finally, Erlang allows transparent distribution, sending messages to remote or local processes is very similar

So Node and Erlang are quite different beasts.

But hey, at least someone is willing to answer without insults. So thank you for that!

Isn’t that exactly what you are doing? Waiting for network IO, caching that to memory and sending them to “database” of sorts when done. When you consider that Node has been doing multi-core/process things for some time now, it’s exactly what you were describing of. Node applications even scale the same way.

Personally, I’d say that healthy developer ecosystem (potential workforce & ready made modules) is far more important than marginally faster solution.

“we adopt the “Let it crash” model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop” — AKA: “we are trying to copy the awesome that is Erlang, without directly referencing Erlang”.

The reason I don’t like Akka is that it uses Java GC, which I am not a fan of… at all. I much prefer Erlang per-process GC for a much smoother / consistent response under heavy load.

I prefer the OTP infrastructure to the Java ecosystem. I like being able to do in place updates, and in place debugging, and in place introspection.

I prefer the hands off approach to scheduling Erlang provides, versus the dispatcher model of Akka.