This statement shows how hype-oriented this team is. Node.js hasn't invented anything new. On top of that, it reimplemented 30 year old concepts badly.
I don't want to start a language war, but a simple comparison of Erlang (which is 20 years old) and Node.js will send this point home:
1) http://stackoverflow.com/questions/3887433/advantages-of-erl...
When Rails came it was truly awesome because the language it used and the framework was so much easier to work with then Java or .Net and some would say better designed then Perl or PHP.
I don't see how Node.js makes developing so much easier than say Rails (unless of course you have a crazy high IO kind of app, which most don't)
However, unless you're implementing servers, I believe it's better to go with synchronous I/O to simplify webapp development. That is exactly what we're doing at Akshell (http://www.akshell.com).
Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives.
At Akshell we're adding a Node based pubsub server with support for both server and browser based subscribers, allowing us to get the best of both worlds: a large number of concurrent connections combined with business logic & message processing using synchronous code.
I don't see how this conflicts with asynchronous I/O unless you're limiting yourself to Twisted/Node.
> Asynchronous I/O is best suited for handling a large number of concurrent connections. However, in the majority of cases these connections are mostly idle, with bursts of activity occurring whenever a message arrives.
This is exactly how you write an Erlang application. Erlang supports asynchronous I/O.
Your viewpoint is accurate if you limit yourself to many of the mainstream languages that are simply terrible at concurrency, but I think this is only temporal. As more work goes onto web apps synchronous I/O simply isn't going to cut it (as many people running popular websites already know).
Most big websites have asynchronous components to address their performance bottlenecks, but the bulk of the business logic uses synchronous I/O and unfashionable languages like PHP as per the 90/10 law: http://en.wikipedia.org/wiki/Program_optimization#Bottleneck...
> Erlang, Haskell, Mozart/Oz all do it superior to something like Node, people just haven't realized it yet so a language that people want to use can be built.
Someday....someday...
The advantage of Node.js over Erlang is that it makes scalable I/O available in a mainstream high-level language. I do not call Erlang mainstream. Although I do think Node.js is a bit overhyped; Ruby's EventMachine and Python's Twisted provide similar functionality, and in particular EventMachine is extremely well-written.
Erlang is language for building massively distributed applications, which is achieved via message passing.
Node.js is event-driven framework build on top of V8 JavaScript engine. It doesn't scale outside of single machine.
I can't imagine a project, for which both: Erlang and Node.js could be considered as right tools for the same job.
I see your argument for language vs framework, I just don't think it matters. Erlang already has a concurrency solution, and it's baked into the language. NodeJS is a solution to concurrency for a language that doesn't have one. I see comparing the two as valid because the question we are discussing how to solve the problem of performing concurrent work.
Why do people use Node.js? Because it solves concurrency issues or because it's easy to use JavaScript application server?
Why do people use Erlang? Because it solves concurrency issues or because it's massively distributed and fault-tolerant system?
Just look at the popular projects and communities behind those two projects :)
Don't get me wrong, I agree that both solve concurrency issues, but this is just tiny part on which they overlap and I don't believe that they are meant to solve the same problems.
The fact that it's built on top of the V8 JavaScript engine says nothing about anything. And the statement "it doesnt' scale outside of a single machine" is just patently false. It has support for sockets, which gives it immediately the ability to scale outside of a single machine.
How do you think remote processes are communicated with/and or spawned in beam (Erlang is built on top of a virtual machine too! imagine that)?
Uh, huh--sockets.