6 ms·

Node.js is Human

30 points by jondavidjohn 12y ago

th0br0 12y ago
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")
- michaelsbradley 12y ago
  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/ http://swannodette.github.io/mori/ [2] https://github.com/clojure/core.async https://github.com/clojure/core.async [3] http://sweetjs.org/ http://sweetjs.org/ [4] http://esprima.org/ http://esprima.org/ [&] http://marijnhaverbeke.nl/acorn/ http://marijnhaverbeke.nl/acorn/
- igravious 12y ago
  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 12y ago
    yay, thanks for the spellcheck... I'll make sure to do that next time.
- _random_ 12y ago
  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.
rco8786 12y ago
There are lots of non-blocking architectures that have been around since before node, not "because of it".
- hacknat 12y ago
  As Isaac Schlueter has said, "non-blocking i/o is as old as the land itself."
- jondavidjohn 12y ago
  Sure, nothing is new under the sun, but it's hard to argue that node has not brought it mainstream, where others have not.
pkinsky 12y ago
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 12y ago
  I'd love to read more about Future[T] and how that type works. Got any more reading on it?
  - pkinsky 12y ago
    There's a nice overview here: http://docs.scala-lang.org/overviews/core/futures.html http://docs.scala-lang.org/overviews/core/futures.html
eldude 12y ago
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#Cooperative_multitasking http://en.wikipedia.org/wiki/Computer_multitasking#Cooperati...
slashnull 12y ago
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-cancer.html http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cance... There. Galactic equilibrium re-established.
hacknat 12y ago
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 12y ago
  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 12y ago
    Fair enough.
vixen99 12y ago
its success
jdlshore 12y ago
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.)

30 points by jondavidjohn 12y ago

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

michaelsbradley 12y ago
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/ http://swannodette.github.io/mori/ [2] https://github.com/clojure/core.async https://github.com/clojure/core.async [3] http://sweetjs.org/ http://sweetjs.org/ [4] http://esprima.org/ http://esprima.org/ [&] http://marijnhaverbeke.nl/acorn/ http://marijnhaverbeke.nl/acorn/
igravious 12y ago
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 12y ago
  yay, thanks for the spellcheck... I'll make sure to do that next time.
_random_ 12y ago
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.

rco8786 12y ago

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

hacknat 12y ago
As Isaac Schlueter has said, "non-blocking i/o is as old as the land itself."
jondavidjohn 12y ago
Sure, nothing is new under the sun, but it's hard to argue that node has not brought it mainstream, where others have not.

pkinsky 12y ago

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 12y ago
I'd love to read more about Future[T] and how that type works. Got any more reading on it?
- pkinsky 12y ago
  There's a nice overview here: http://docs.scala-lang.org/overviews/core/futures.html http://docs.scala-lang.org/overviews/core/futures.html

eldude 12y ago

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#Cooperative_multitasking http://en.wikipedia.org/wiki/Computer_multitasking#Cooperati...

slashnull 12y ago

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-cancer.html http://widgetsandshit.com/teddziuba/2011/10/node-js-is-cance... There. Galactic equilibrium re-established.

hacknat 12y ago

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 12y ago
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 12y ago
  Fair enough.

vixen99 12y ago

its success

jdlshore 12y ago

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