Node.js is Backwards
71–80 of 90 posts
Re: Node.js is Backwards
#72Earlier 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.
Re: Node.js is Backwards
#73Earlier 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.
Re: Node.js is Backwards
#74I'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…
Re: Node.js is Backwards
#75Sure, 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
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
#76Earlier 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."
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
#77OK 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.
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
#78Earlier 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.
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
#79Earlier 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.
Re: Node.js is Backwards
#80Earlier 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_...