4 ms·

"I/O has been done wrong for the last 30 years,” he said, referring to the fact that Node.js allows servers to react to specific events." This statement shows

"I/O has been done wrong for the last 30 years,” he said, referring to the fact that Node.js allows servers to react to specific events." 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-erlang-over-something-like-node-js http://stackoverflow.com/questions/3887433/advantages-of-erl... 2) http://journal.dedasys.com/2010/04/29/erlang-vs-node-js http://journal.dedasys.com/2010/04/29/erlang-vs-node-js

piotrSikora 15y ago
Why in the world would you compare these two? It's apples to oranges...
- sausagefeet 15y ago
  How? They are both trying to solve the same problem and they take different approaches, what is unreasonable about comparing that?
  - piotrSikora 15y ago
    And what problem is that exactly? Just please don't say concurrency and/or scalability, because it's huge generalization. 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.
    - sausagefeet 15y ago
      They are both providing a model for performing concurrent work. Erlang is quite good at writing distributed applications, but not everyone is writing distributed applications. WebMachine and Mochi both address a similar set of problems someone would want to address with Node. To argue that the problems people want to solve in Erlang and Node do not overlap is amazingly unimaginative.
      - piotrSikora 15y ago
        Yes, but now you're comparing WebMachine and Mochi to Node, which is fine...
        sausagefeet 15y ago
        So you can imagine a project for which Node and Erlang are valid solutions? 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.
        piotrSikora 15y ago
        OK, let me put this differently. 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.
    - apgwoz 15y ago
      > Node.js is event-driven framework build on top of V8 JavaScript engine. It doesn't scale outside of single machine. 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.
FooBarWidget 15y ago
Don't compare Erlang to Node.js. Erlang is not a good implementation of evented servers. I'm not saying that Erlang is a bad implementation of evented servers, I'm saying that Erlang doesn't implement the evented architecture at all. Instead Erlang with its lightweight processes is more similar to the plain old 1-thread-per-IO-channel worker model except Erlang can spawn many more processes than the OS can spawn OS threads. Not that there's anything wrong with this; Erlang's processes are so lightweight that you can essentially get the same amount of scalability as evented servers. 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.
- sausagefeet 15y ago
  I disagree with you. Determining how well they solve the problem they claim to solve relative to each other is a valid comparison.
va_coder 15y ago
I think Node.js is neat but could someone tell me how it's so awesome. 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)
- FooBarWidget 15y ago
  Node.js isn't easier than Rails, at least for the things that Rails is good at. Node.js is good for apps that require high I/O concurrency, things like chat servers, but much much worse than Rails for pretty much everything else. I see Node.js only being useful for special types of applications, it is not the next Rails or anything like that. Unfortunately I foresee that people will (ab?)use Node.js as some kind of Rails replacement.
  - va_coder 15y ago
    Thanks for the insight
- olegp 15y ago
  To add to what FooBarWidget said, I do believe that there are inherent advantages to using JavaScript on the server for developing webapps. For one, due to the dominance of JavaScript within browsers, it is the one dynamic language we will be stuck with for at least the next 20 years! 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 http://www.akshell.com).
  - sausagefeet 15y ago
    Why do you believe synchronous I/O is better for building web apps? Certainly it is worse for utilizing resources. The problem seems to be that most of the internet is about 20 years behind when it comes to performing I/O well. 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.

piotrSikora 15y ago

Why in the world would you compare these two? It's apples to oranges...

sausagefeet 15y ago
How? They are both trying to solve the same problem and they take different approaches, what is unreasonable about comparing that?
- piotrSikora 15y ago
  And what problem is that exactly? Just please don't say concurrency and/or scalability, because it's huge generalization. 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.
  - sausagefeet 15y ago
    They are both providing a model for performing concurrent work. Erlang is quite good at writing distributed applications, but not everyone is writing distributed applications. WebMachine and Mochi both address a similar set of problems someone would want to address with Node. To argue that the problems people want to solve in Erlang and Node do not overlap is amazingly unimaginative.
    - piotrSikora 15y ago
      Yes, but now you're comparing WebMachine and Mochi to Node, which is fine...
      - sausagefeet 15y ago
        So you can imagine a project for which Node and Erlang are valid solutions? 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.
        piotrSikora 15y ago
        OK, let me put this differently. 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.
  - apgwoz 15y ago
    > Node.js is event-driven framework build on top of V8 JavaScript engine. It doesn't scale outside of single machine. 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.

FooBarWidget 15y ago

Don't compare Erlang to Node.js. Erlang is not a good implementation of evented servers. I'm not saying that Erlang is a bad implementation of evented servers, I'm saying that Erlang doesn't implement the evented architecture at all. Instead Erlang with its lightweight processes is more similar to the plain old 1-thread-per-IO-channel worker model except Erlang can spawn many more processes than the OS can spawn OS threads. Not that there's anything wrong with this; Erlang's processes are so lightweight that you can essentially get the same amount of scalability as evented servers. 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.

sausagefeet 15y ago
I disagree with you. Determining how well they solve the problem they claim to solve relative to each other is a valid comparison.

va_coder 15y ago

I think Node.js is neat but could someone tell me how it's so awesome. 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)

FooBarWidget 15y ago
Node.js isn't easier than Rails, at least for the things that Rails is good at. Node.js is good for apps that require high I/O concurrency, things like chat servers, but much much worse than Rails for pretty much everything else. I see Node.js only being useful for special types of applications, it is not the next Rails or anything like that. Unfortunately I foresee that people will (ab?)use Node.js as some kind of Rails replacement.
- va_coder 15y ago
  Thanks for the insight
olegp 15y ago
To add to what FooBarWidget said, I do believe that there are inherent advantages to using JavaScript on the server for developing webapps. For one, due to the dominance of JavaScript within browsers, it is the one dynamic language we will be stuck with for at least the next 20 years! 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 http://www.akshell.com).
- sausagefeet 15y ago
  Why do you believe synchronous I/O is better for building web apps? Certainly it is worse for utilizing resources. The problem seems to be that most of the internet is about 20 years behind when it comes to performing I/O well. 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.