How is Node.js evented system different than the actor pattern of Akka?

Question

I've worked with Node.js for a little while and consider myself pretty good with Java. But I just discovered Akka and was immediately interested in its actor pattern (from what I understand).

Now, assuming my JavaScript skills were on par with my Scala/Java skills, I want to focus on the practicality of either system. Especially in the terms of web services.

It was my understanding that Node is excellent at handling many concurrent operations. I imagine a good Node web service for an asset management system would excel at handling many users submitting changes at the same time (in a large, heavy traffic application).

But after reading about the actors in Akka, it seams it would excel at the same thing. And I like the idea of reducing work to bite-sized pieces. Plus, years ago I dabbled in Erlang and fell in love with the message passing system it uses.

I work on many applications that deal with complex business logic and I'm thinking it's time to jump heavier into one or the other. Especially upgrading legacy Struts and C# applications.

Anyway, avoiding holy wars, how are the two systems fundamentally different? It seems both are geared towards the same goal. With maybe Akka's "self-healing" architecture having an advantage.

EDIT

It looks like I am getting close votes. Please don't take this question as a "which is better, node or akka?". What I am looking for is the fundamental differences in event driven libraries like Node and actor based ones like Akka.

Answer 1

Without going into the details (about which I know too little in the case of Node.js), the main difference is that Node.js supports only concurrency without parallelism while Akka supports both. Both systems are completely event-driven and can scale to large work-loads, but the lack of parallelism makes it difficult in Node.js (i.e. parallelism is explicitly coded by starting multiple nodes and dispatching requests accordingly; it is therefore inflexible at runtime), while it is quite easy in Akka due to its tunable multi-threaded executors. Given small isolated units of work (actor invocations) Akka will automatically parallelize execution for you.

Another difference of importance is that Akka includes a system for handling failure in a structured way (by having each actor supervised by its parent, which is mandatory) whereas Node.js relies upon conventions for authors to pass error conditions from callback to callback. The underlying problem is that asynchronous systems cannot use the standard approach of exceptions employed by synchronous stack-based systems, because the “calling” code will have moved on to different tasks by the time the callback’s error occurs. Having fault handling built into the system makes it more likely that applications built on that system are robust.

The above is not meant to be exhaustive, I’m sure there are a lot more differences.

Answer 2

I didn't yet use Akka, but it seems it's erlang-like but in java. In erlang all processes are like actors in Akka, they have mailboxes, you can send messages between them, you have supervisors etc.

Node.js uses cooperative concurrency. That means you have concurrency when you allow it (for example when you call io operation or some asynchronous event). When you have some long operation (calculating something in long loop) whole system blocks.

Erlang uses preemptive task switching. When you have long loop, system can pause it to run other operation and continue after some time. For massive concurrency Node.js is good if you do only short operations. Both support millions of clients: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/

In java you need threads to do any concurrency, otherwise you can't pause execution inside function which erlang does (actually erlang pauses between function calls, but this hapens with all functions). You can pause execution between messages.