Node.js is Human | Hacker News Reader

Node.js is Human

jondavidjohn.com

30 pointsjondavidjohn18 comments

The real surprise of Node.js for me has been this point:

> In Node, everything runs in parallel except your code.

Guaranteed single-threaded execution of my code combined with a great concurrency story has been a revelation. I can do all kinds of stuff that would just be flat-out stupid in a multithreading language (like naïve performance monitoring and caching using global variables) and it's easy. I ask myself, "do I have a race condition?" then I look at the code, make sure there's no asynchronous callback between my global read and my global write, and say, "Nope! Ship it!"

Really, it's been a pleasure.

(Before anyone accuses me of ivory-tower-itis, this opinion is based on the production-grade, money-generating HTTP server, CMS, and site I wrote in Node.js: http://www.letscodejavascript.com . And yes, the callback pyramid of doom sucks, I'm not saying it doesn't.)

Monadic composition of futures for nonblocking servers is the way to go, but in javascript? With no for comprehension syntax? With no ability to express the asynchronous nature of your code via the type system using Future[T]?

Node.js does some amazing things, but it builds on very unsound soil, namely javascript.

Edit: to end on a positive note, Scala is doing some great things with nonblocking systems. Check out the play framework, finagle, Future and Promise types in the core library, etc. It's not quite Haskell, but it has the advantage of running on the JVM with easy Java interop.

I'd love to read more about Future[T] and how that type works. Got any more reading on it?

There's a nice overview here: http://docs.scala-lang.org/overviews/core/futures.html

By that logic, anything that abstracts parallelism away is "human". Actors are human. akka.io is human. Erlang is "human"... but the latter two are actually some weird meta-human because they provide true parallelism.

One could as well propose a counter-theory: Node.js is _not_ (or rather anti-) human, because it takes away the joy of solving complex parallelism-related issues and thus limits a human's intellectual development.

(Oh and your last word contains a typo: "excersize")

JavaScript's (and so Node's) limited concurrency primitives and unfettered mutability have, in my experience, resulted in its making a number of concurrency-related problems harder to deal with, not easier.

Mutability can be tamed with the help of libraries that provide immutable collections[1]. The best concurrency facility for JavaScript that I've found is core.async[2], but you can't really mimic it with vanilla JavaScript as the language doesn't provide macros. It might be interesting, though, to see if the core.async patterns could be implemented in terms of sweet.js[3] and with the help of esprima or acorn[4].

[1] mori, for example: http://swannodette.github.io/mori/

[2] https://github.com/clojure/core.async

[3] http://sweetjs.org/

[4] http://esprima.org/

[&] http://marijnhaverbeke.nl/acorn/

typos: excreeting, benifit (singular), disatisfaction, concurency, transfering, asyncronous (in an article about parallelism, oops!), everytime, asyncronous (again), benifits (plural), philisophically, asyncronous (yet again), and finally excersize

yay, thanks for the spellcheck... I'll make sure to do that next time.

I think he means that "to err is human". It is very easy to make frustrating mistakes in JavaScript which is not just dynamic, but even weakly-typed. Following that Node.js is obviously most human.

I agree with some of the technical things that he is saying (though he's several years late to this conversation), but saying things like,

"This provides 90% of the benifits [sic] of parallelism for the common use case without presenting the developer with additional complexity."

is disingenuous. Where does your "90%" come from? Just say, "a lot of benefits" or "many benefits".

Moving onto the question of analogizing human thought as non-blocking versus threaded is tortured and distracting from any main point someone might make.

It is a lot easier for human beings to write code in nodeJS without f*ing themselves over, but that isn't necessarily the case because people understand any better what's happening underneath the covers (do really understand what epoll, select, or kqueue are actually doing at the kernel level?). It's because node's paradigm simply prevents you from being stupid with IO.

You can still be stupid with node though. Back to the "90%" claim, quite a bit of parallelism is used to make computation faster. Node can sometimes still provide some game when computation is a bottleneck. However, since you have to serialize and de-serialize in and out of v8 when you need to thread if you're doing a lot of large computations with large data-structures then node sucks.

Point taken on the 90%, updated the post.

I don't think anyone is saying node is aways awesome and never sucks, I am just pointing out that it solves one of the most common problems with network/web applications. Which you also point out, (the platform) "being stupid with I/O".

Fair enough.

There are lots of non-blocking architectures that have been around since before node, not "because of it".

As Isaac Schlueter has said, "non-blocking i/o is as old as the land itself."

Sure, nothing is new under the sun, but it's hard to argue that node has not brought it mainstream, where others have not.

tldr; Node.js' super light-weight cooperative-multitasking[1] allows IO optimizations only humans understand.

I agree with this whole-heartedly, but it does put the limitation on the human, and not on the computer, which is actually the opposite direction we want to go. I don't think we're there yet, so in the meantime, node.js is fantastic for when you need/want to hyper-optimize your critical code path for response time.

One thing I would add is that node.js makes job-queueing, background-task handling, side-effect inducing trivial since it makes networked IO / SOA trivial. In other words, having a separate process deal with anything not necessary for returning a response is almost effortless, allowing your responses to always take the minimum time necessary, freeing your client to continue.

[1] http://en.wikipedia.org/wiki/Computer_multitasking#Cooperati...

I will reply to a completely content-free post with another, mildly less content-free post.

http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cance...

There. Galactic equilibrium re-established.

its success

Reply on news.ycombinator.com