Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js is Backwards

blog.ankurgoyal.com

Post reply on HN
Print view View original

21–30 of 90 posts

Re: Node.js is Backwards

#21

Post by hp »

It would be pretty simple conceptually (maybe not practically) to make node.js work in an actor-like way, here's a piece of toy code I wrote that does it for JS (not node, but no reason the same couldn't be done for node): http://blog.ometer.com/2010/11/28/a-sequential-actor-like-ap...

By "actor-like way" here I just mean a code module ("actor") sees one thread (at a time), and the runtime takes care of the details of scheduling threads when a module has an event/message/request to process. Also I guess avoiding callbacks. But you could be more Erlang-ish/Akka-ish in more details if you wanted.

node.js punts this to the app developer to instead run a herd of processes. In most cases that's probably fine, but in theory with one process and many threads, the runtime can do a better job saturating the CPU cores because it can move actors among the threads rather than waiting for the single-threaded process an actor happens to be in to become free. The practical situations where this comes up, I admit, are probably not that numerous as long as you never use blocking IO and are basically IO-bound. (Only CPU-intensive stuff would cause a problem.)

btw this has been hashed out to death on the node.js list: http://groups.google.com/group/nodejs/browse_thread/thread/c...

Re: Node.js is Backwards

#22

Post by spoondan »

m0th87 wrote: post #16
jessedhillon wrote: post #15

Earlier quoted context omitted.

> Using the same language at both the client and server end has some serious benefits. What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)

Here's a case study: an open source project I made with node.js; https://github.com/node-bus/node-bus It's a distributed pub-sub engine, so one client can publish an event, and the others on the server will receive it. Probably about half the code is shared between the server and client. That means less bugs and easier maintenance. Technically there are tools that will convert, say, Haskell to Javascript so that you…

The Google Web Toolkit (GWT) is a widely used Java-to-JavaScript compiler:

http://code.google.com/webtoolkit/

Re: Node.js is Backwards

#23

Post by ankrgyl »

ajross wrote: post #20
m0th87 wrote: post #17

Earlier quoted context omitted.

Node does have concurrency. It does not have parallelism. This is an important distinction: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...

That seems too nitpicky to me. You can use those definitions if you like, but it's not the common usage. To most programmers those terms are synonyms. In my experience, people trying to be precise about architectures like node.js use the term "asynchronous" and not "concurrent". Calling node.js concurrent obscures the important fact under discussion: namely that it won't scale beyond one CPU in a world where 8-core s…

The distinction between parallelism and concurrency is extremely important. The guys who wrote Real World Haskell did a good job of explaining it here http://book.realworldhaskell.org/read/concurrent-and-multico... (explanation has nothing to do with Haskell).

In essence, concurrency has to do with systemsy stuff- how to do things that might overlap without causing problems (race conditions). On the other hand, parallelism is about breaking a problem into smaller parts and attacking it in pieces. The problem with most languages is that they require the programmer to worry about both at the same time; however, languages like Erlang alleviate most of these problems, the biggest of which is shared state.

Re: Node.js is Backwards

#24

Post by nzoschke »

alnayyir wrote: 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 people point to examples of large production Node deployments?

Re: Node.js is Backwards

#25

Post by [deleted] »

cwp wrote: post #14

What a bunch of gobbledygook. People tend to lump Node and Erlang together because they both avoid shared-state concurrency. But they're completely opposite approaches: Erlang has concurrency but no shared state. Node has shared state but no concurrency. Not that you'd get this from the article.

[deleted]

Re: Node.js is Backwards

#26

Post by superrad »

dreamdu5t wrote: post #6

It seems like most people are using nodejs for the web, and nodejs includes a library for HTTP. What are some good web libraries for Erlang?

Nitrogen is well equipped web framework http://nitrogenproject.com/

You have mochiweb ( https://github.com/mochi/mochiweb ) and misultin ( https://github.com/ostinelli/misultin ) if you want something a bit more like node

Re: Node.js is Backwards

#27

Post by jrockway »

edtechre wrote: post #19
m0th87 wrote: post #17

Earlier quoted context omitted.

Node does have concurrency. It does not have parallelism. This is an important distinction: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...

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

#28

Post by jessedhillon »

m0th87 wrote: post #16
jessedhillon wrote: post #15

Earlier quoted context omitted.

> Using the same language at both the client and server end has some serious benefits. What are these benefits? Are they really exclusive to Node? (or if not exclusive, then vastly simpler with Node)

Here's a case study: an open source project I made with node.js; https://github.com/node-bus/node-bus It's a distributed pub-sub engine, so one client can publish an event, and the others on the server will receive it. Probably about half the code is shared between the server and client. That means less bugs and easier maintenance. Technically there are tools that will convert, say, Haskell to Javascript so that you…

I looked through your shared/util.js and, while I don't want to take anything away from your project, it doesn't seem to me that there is much of a case for significant and useful code sharing in Node. When I think of code sharing, I expect something like Luna, from Asana http://asana.com/luna/

Instead, the examples of shared code in Node are always simple utility functions, validators and the like. While it helps not to have to rewrite those, it's not groundbreaking. Facilitating the sharing of state between client and server -- hopefully irrespective of the server-side language -- would be a much better goal, IMO.

Re: Node.js is Backwards

#29

Post by khookie »

edtechre wrote: post #19
m0th87 wrote: post #17

Earlier quoted context omitted.

Node does have concurrency. It does not have parallelism. This is an important distinction: http://stackoverflow.com/questions/1050222/concurrency-vs-pa...

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.

There is longevity in nodejs. As long as Javascript remains king on the client-side, you can pretty much guarantee nodejs will have a future.

Re: Node.js is Backwards

#30

Post by sausagefeet »

jrockway wrote: post #27
edtechre wrote: post #19

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.

Clearly it's not that easy unless you plan for it from the beginning. One benefit of Erlang is that you have to structure you code like a distributed application. You can mess that up, but it's harder.
Post reply on HN