Node.js is Backwards

http://blog.ankurgoyal.com/post/6433642218/node-js-is-backwards

by ankrgyl • 15 years ago

144 85 15 years ago

blog.ankurgoyal.com

thesz3• 15 years ago

Article is quite refreshing, given booming Node.js popularity.

This is what I thinking when reading all the discussions about Node.js (mainly here, at HN).

Disclaimer: I don't program in JS, and I won't touch it without six feet pole (read: code generator from some higher-level strongly-typed language).

dscape• 15 years ago

Very well written article summarizing some discussions that are apparently common in the erlang community.

alnayyir5• 15 years ago

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.

m0th875• 15 years ago

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.

jessedhillon6• 15 years ago

> 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)

alnayyir5• 15 years ago

>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.

otterley• 15 years ago

> Using the same language at both the client and server end has some serious benefits

Like what? I hear this argument all the time, but it's always unsubstantiated.

In my experience, the choice of language is less important than the programmer's understanding of facts that have little to do with the language itself.

If you are developing client-side browser code, for instance, then you have little choice but to use Javascript.

But learning JavaScript is not the hard part: mainstream programming languages, in and of themselves, are rarely difficult to master.

On the contrary, the skill that separates the superior engineers from the inferior ones is the mastery of the environment that the program operates in.

For front-end developers, it is an intricate understanding of how browsers work (i.e., the DOM and supported events) and some good understanding of how to optimize requests back to the server. (There is probably much more they know than this, but I'm not a front-end developer.)

Similarly, back-end developers have much to learn about how to efficiently and reliably serve (hopefully) many thousands of requests per second. They need to understand the limitations of their servers, how to manage memory and storage effectively, and build reliable, operable services.

For both types, these skills often take many years to master, and they are hardly interchangeable. Consider that developers themselves often describe themselves as "front-end" and "back-end" people. The fact that you can now use JavaScript on the server side does little to disturb this reality; and things wouldn't change much if you could run Perl or Python or Ruby in the browser tomorrow.

nzoschke• 15 years ago

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?

weixiyen2• 15 years ago

plurk

daleharvey2• 15 years ago

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

daleharvey2• 15 years ago

I know both erlang and node and take node seriously

skybrian• 15 years ago

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

jamwt• 15 years ago

.. or erlang processes. Or python greenlets. Or Haskell forkIO threads. Or libcoroutines.. Etc.

See: http://news.ycombinator.com/item?id=1549023

uriel• 15 years ago

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.

dreamdu5t• 15 years ago

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?

jessedhillon6• 15 years ago

Erlang HTTP server: http://www.erlang.org/doc/apps/inets/http_server.html

Webmachine, "A REST-based system for building web applications": https://bitbucket.org/justin/webmachine/wiki/Home

superrad• 15 years ago

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

arturadib• 15 years ago

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.

silentbicycle• 15 years ago

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.

SeoxyS2• 15 years ago

Speaking of concurrent programming and parallelism. If you're not into functional programming, check out Apple's Grand Central Dispatch[1] and Objective-C Blocks[2].

Unless you write your own Objective-C http server and run it on Mac OS X Server (it's not that hard, I've done it), this isn't very useful for Web programming. However, if you're comparing the languages / frameworks themselves (you can use all three to code command line tools, for example), GCD becomes a very seductive option.

GCD works by throwing code blocks (obj-c closures) into queues, and letting the runtime do its magic. You can have it execute code synchronously, asynchronously, or in parallel.

GCD will optimize and distribute your blocks the the available CPU cores. You can even enumerate using blocks, and instead of doing loop iterations one by one, it'll distribute them to the cores in parallel.

[1] http://en.wikipedia.org/wiki/Grand_Central_Dispatch [2]: http://developer.apple.com/library/ios/#documentation/cocoa/...

BasDirks• 15 years ago

Node is very nice for command line tools!

bittersweet• 15 years ago

I've been hacking away on Obj-C and more specifically MacRuby and did some basic stuff with GCD already, using the async queueing system.

The distributed enumeration sounds interesting, could you point me in the direction of where I can find some more info about that?

SeoxyS2• 15 years ago

You might wanna take a look at dispatch_apply with striding:

http://developer.apple.com/library/mac/#documentation/Darwin...

bitcoins• 15 years ago

My node.js project spreads all node.js i/o across multiple node processes ( in machine, network, or browser ) and creates a distributed EventEmitter across all nodes.

https://github.com/Marak/hook.io

peregrine• 15 years ago

Where were you 4 months ago?

m0th875• 15 years ago

Suggesting Node and Erlang have the same concurrency model is a complete pigeonholing. CPS != Actors.

cwp3• 15 years ago

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.

m0th875• 15 years ago

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

edtechre• 15 years ago

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.

ajross2• 15 years ago

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 servers are routine.

cwp3• 15 years ago

Well, that's debatable. I suppose if you squint a bit, you mentally perform a reverse CPS transform on a Node program and end up with a set of tasks that are executing concurrently. In that case, I'll rephrase: Erlang as parallelism (on adequate hardware) but no shared state; Node has shared state but no parallelism.

Still, given the way Node forces programmers to manually unravel tasks and write everything as callbacks, I'm not inclined to call it "concurrency" even if eg. the processing of a group of web requests overlap in wall-clock time.

hp• 15 years ago

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...

davidhollander2• 15 years ago

> Node.js’s concurrency mechanisms are simply an approximation of Erlang’s.

Lulz? Here's a much simpler explanation: it's a polling server. It's not an intentional approximation of this or that (Erlang), this is just how event loops using select\poll\epoll\kqueue have always worked. Unless you want to do a bunch of extra work and throw in per-core preforking\threading and scrap the libev dependency Node built upon.

ankrgyl3• 15 years ago

Erlang, and other similar efforts like Haskell's forkIO and Python's eventlet/gevent, are also built upon the same fundamentals as libev (and some actually just use libev). But using libev in the way that Node.js does boils down to user-space threads with cooperative scheduling (you yield control every time you make a blocking I/O call). The abstractions that Erlang/Haskell/Python provide let you program in the familiar synchronous, threaded style while retaining the performance advantages of an explicit (e)polling server.

Ted Dziuba explained this well for Python http://teddziuba.com/2010/02/eventlet-asynchronous-io-for-g....

davidhollander2• 15 years ago

>(you yield control every time you make a blocking I/O call)

You're referring to is coroutine vs. continuation passing (callback). This is unrelated to whether you also are also forking into a small number of processes for each core. You can do both. Node simply doesn't yet. Nginx with workers is an example of an asynchronous server that does.

In regards to your link and the coroutine yielding approach: Being able to write psuedoblocking and monkeypatching code is not necessarily a good thing! It encourages you to keep making subrequests sequentially in serial, rather than in parallel as comes natural with using callbacks. It also discourages one from using custom continuation logic such as quorums. Examples of when the yielding approach fails:

- You want to both send and read independently on the same connection without creating multiple coroutines\greenthreads\userthreads per connection.

- You want to continue once 2 of 3 data services have calledback that information was successfully stored

I've written a fast single-core asynchronous server here in Lua without using user space thread yielding that you may be interested in: https://github.com/davidhollander/ox

pkulak• 15 years ago

Does anyone know how well Scala can handle the requirements of a typical Node.js project? IE, thousands of network connections and rather light CPU load overall? Can Scala be a Node.js or Erlang replacement?

gtani• 15 years ago

look at some of the Akka deploys

http://stackoverflow.com/questions/4493001/good-use-case-for...

http://fornax-sculptor.blogspot.com/2010/08/eda-akka-as-even...

(minimal code example)

http://groups.google.com/group/akka-user/browse_thread/threa...

There's probably similar cookbook examples and benchmark/ overhead per process measurements for F# MailboxProcessors, if you're curious

mattking• 15 years ago

> Node.js appeals to people who already know Javascript and don’t want to learn a new language

This is a blanket statement that perhaps displays the author's opinion on Javascript as a language itself.

premchai21• 15 years ago

I don't see how it does. Making note of the entrenchment bonus granted by a language already known by much of the target audience isn't necessarily making a value statement about the bonus or secondary effects thereof.

aufreak3• 15 years ago

It looks to me like all this debate has no observable consequence on the respective programming communities. Node folks will program the Node way and love it and Erlang folks will program the Erlang way and love it. The creators of neither are trying to woo the other and they perfectly well understand operationally where each system stands.

hannesw• 15 years ago

I think the opinions expressed in this article are valid.

However, I don't think the inability of current JavaScript to do async I/O without callbacks is Node's biggest problem. As others have said, it works for smaller projects (and even has some geek appeal). And as Havoc Pennington and Dave Herman have explained, generators (which are coming with ECMAScript Harmony) and promises will eventually provide a very nice solution. So Node has a path to grow out of the callback model without giving up its single threaded paradigm.

http://blog.ometer.com/2010/11/28/a-sequential-actor-like-ap...

http://blog.mozilla.com/dherman/2011/03/11/who-says-javascri...

The bigger problem (which I don't see getting solved anywhere down the road) is the lack of preemptive scheduling, which is available in Erlang or on the JVM. What you see under high load with Node is that latency is spread almost linearly over a very wide spectrum, from very fast to very slow, whereas response times on a preemptively scheduled platform are much more uniform.

http://jlouisramblings.blogspot.com/2010/12/differences-betw...

And no, this is something that can't be solved by distributing load over multiple CPU cores. This is problem really manifests itself within each core, and it is a direct consequence of Node's single threaded execution model. If anybody knows how to solve this without resorting to some kind of preemptive threading I'd be very curious to hear about it.

Khao• 15 years ago

I've read a lot about Node and watched Ryan Dahl's introduction to Node and maybe the author of this post should have done that too. At no moment does Ryan talks about Erlang and having anything to do with Erlang's way of thinking. Node was built to use javascript's awesome V8 engine and its event loop that many people already know and love to provide evented IO. I love Node and I think it is a great project, which has nothing to envy about Erlang.

This is like saying "This Honda Civic clearly sucks compared to my helicopter. Let me write you an article about everything that my helicopter does betting that your Civic". Clearly the Civic was build for another purpose and so the comparison is void.

mikemaccana• 15 years ago

Edit: looks as if Erlang does indeed have its own, separate definition for lightweight process. See the disambiguation page on http://en.wikipedia.org/wiki/Light-weight_process. How very poor of whoever started misusing an existing concurrency term to refer to something else - as if discussing these matters isn't already difficult enough.

Could someone familiar with Erlang please clarify:

"To understand why this is misleading, we need to go over some background information. Erlang popularized the concept of lightweight processes (Actors) and provides a runtime that beautifully abstracts the concurrency details away from the programmer. You can spawn as many Erlang processes as you need and focus on the code that functionally declares their communication. Behind the scenes, the VM launches enough kernel threads to match your system (usually one per CPU) "

In common Unix tools like 'ps' and 'top' the term 'Lightweight Process' is used as a synonym for OS thread, eg, the LWP column in 'ps -eLf' shows the thread ID.

In this article, LWPs seem to be different from threads? Is this correct? If they're not threads, what are they?

jamesaduncan• 15 years ago

Fair catch, I could have chosen more precise words.

Sym3tri• 15 years ago

Uh oh. Cue flame war.

Node.js is Backwards

Related Stories