Live data from Hacker News

Node.js is Backwards

blog.ankurgoyal.com

71–80 of 90 posts

Re: Node.js is Backwards

#72

Earlier quoted context omitted.

The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism of the OS itself by pre-forking the Node server. NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. That's why I predict similar technologies built on Erlang, Scala, and Go will have more longevity than NodeJS.

NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. Well, you do with node what you do with anything: if you have 4 CPU cores, run 4 copies of your app. Problem solved.

Imagine your app has 16GiB of precomputed tables in memory...

Re: Node.js is Backwards

#73

Earlier quoted context omitted.

The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism of the OS itself by pre-forking the Node server. NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. That's why I predict similar technologies built on Erlang, Scala, and Go will have more longevity than NodeJS.

NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. Well, you do with node what you do with anything: if you have 4 CPU cores, run 4 copies of your app. Problem solved.

This allows you to serve more clients simultaneously, but not to serve any given client faster i.e. you get higher throughput but not lower latency.

Re: Node.js is Backwards

#74
post #4

I've been saying this about Erlang and Node for awhile, and I don't know anybody who knows both Erlang and JS that takes Node seriously.

I love Node for many things, but I agree with this sentiment. At work, every time we undertake a project in Node, it just doesn't work at scale, and it has to get re-implemented in Erlang. A lot of this is for personnel reasons. To all of us Node is a neat new toy, where a few engineers are Erlang wizards. If Node crashes we don't have any experience debugging it. If it locks up there's little intuition why. Can peop…

https://developer.palm.com/index.php?id=2109&option=com_...

Re: Node.js is Backwards

#75
post #8
post #5

Sure, it's the reverse of goroutines, which allow you to do easy asynchronous programming using synchronous code.

.. or erlang processes. Or python greenlets. Or Haskell forkIO threads. Or libcoroutines.. Etc. See: http://news.ycombinator.com/item?id=1549023

Erlang has a slightly different but largely equivalent model, but the other alternatives you mention lack Go's channels and/or the select construct which is one of the greatest things about the language.

When I found that Stackless Python didn't have a way to read/write on multiple channels at once I was quite shocked.

Re: Node.js is Backwards

#76
post #57

Earlier quoted context omitted.

The article is not "gobbledygook". A well known limitation of NodeJS is its lack of support for parallelism. You have to try to take advantage of parallelism of the OS itself by pre-forking the Node server. NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. That's why I predict similar technologies built on Erlang, Scala, and Go will have more longevity than NodeJS.

I used the word "gobbledygook" because the article is poorly written, not because I think he's wrong to criticize Node. Reread the paragraph on Node and tell me it doesn't meet the Wikipedia definition: "text containing jargon or especially convoluted English that results in it being excessively hard to understand."

poorly written

I had no trouble understanding the paragraph that you complain about and found the article to be very well written.

Where do you see excessive jargon or convolution?

Re: Node.js is Backwards

#77

OK fine, Duncan might not have chosen the best words when comparing Node to Erlang. But how's Node.js "backwards"? It seems to me that the author has picked on one statement by one individual, and turned that into a link-bait.

Having to manage callback control flow by hand.

There's a lot of research surrounding CPS-transformed code (look at Orbit (http://people.csail.mit.edu/riastradh/t/adams86orbit.pdf), for example), but nobody ever needed to manage it by hand.

For a more meaningful comparison between Node and Erlang, look at how they handle errors.

Re: Node.js is Backwards

#78
post #11

Earlier quoted context omitted.

I know both and I take Node seriously. Using the same language at both the client and server end has some serious benefits. And web servers are mostly shared-none, so not having first-class support for communication between Node processes is not that big of a deal. Node has its niche.

>Using the same language at both the client and server end has some serious benefits. The functionality implemented is mutually exclusive. This canard needs to die.

The functionality implemented is mutually exclusive

Sorry, but what is that supposed to mean?

The functionality on either end of a client/server application is usually not "mutually exclusive". They're two sides of the same coin and could indeed benefit tremendously from code sharing. Just because the potential has barely been realized so far doesn't mean it doesn't exist.

Re: Node.js is Backwards

#79

Earlier quoted context omitted.

That's not their backend, it's just servicing a front-end feature.

It's doing what normally Erlang would have been used for, which answers the original question. It's a node.js deployment, and very early version one at that. I'm not really sure what your point is.

Plurk actually gave up on node after failing to optimize their service and went back to Netty (http://amix.dk/blog/post/19577). A better answer is this: https://github.com/joyent/node/wiki/Projects,-Applications,-...

Re: Node.js is Backwards

#80

Earlier quoted context omitted.

I love Node for many things, but I agree with this sentiment. At work, every time we undertake a project in Node, it just doesn't work at scale, and it has to get re-implemented in Erlang. A lot of this is for personnel reasons. To all of us Node is a neat new toy, where a few engineers are Erlang wizards. If Node crashes we don't have any experience debugging it. If it locks up there's little intuition why. Can peop…

https://developer.palm.com/index.php?id=2109&option=com_...

Putting it in words for those too lazy to click: node.js is built into webOS.
Post reply on HN