
Node.js is Human - jondavidjohn
http://jondavidjohn.com/nodejs-is-human/
======
jdlshore
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](http://www.letscodejavascript.com) . And
yes, the callback pyramid of doom sucks, I'm not saying it doesn't.)

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

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

~~~
pkinsky
There's a nice overview here: [http://docs.scala-
lang.org/overviews/core/futures.html](http://docs.scala-
lang.org/overviews/core/futures.html)

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

~~~
igravious
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

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

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

~~~
jondavidjohn
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".

~~~
hacknat
Fair enough.

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

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

------
eldude
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...](http://en.wikipedia.org/wiki/Computer_multitasking#Cooperative_multitasking)

------
slashnull
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...](http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cancer.html)

There. Galactic equilibrium re-established.

------
vixen99
its success

