Hacker News new | ask | show | jobs
by StavrosK 5381 days ago
Seriously, it sounds like Python handles these sorts of cases much better, with "yield". I wonder why everyone suddenly discovered JS for asynchronous programming and rushed to it when Twisted has existed for years. Is it because of V8?
2 comments
baudehlo 5381 days ago
It's partly because of the performance of V8 (my SMTP server, Haraka, is about 8-10 times faster than the Perl version I worked on, Qpsmtpd, for example), and partly because of the "sync library" problem - with Perl (or Python) most libraries that access things on the network or on disk are written synchronously. That's not the case with Node - everything is assumed to be async.

I've written a LOT of async code in Perl and C, and ran across this problem countless times. It really is a blessing to not have to worry about it.

link
dspillett 5381 days ago
I don't thing a lot of node's traction is coming from Python programmers (though when I last looked at Python I got the impression Twisted has a reputation for being spottily documented, has that improved in recent years?).

The attraction of using Javascript server-side for many is the possibility of using the same language client- and server- side, with the relative ease of a native data encapsulation (JSON) for transferring state between the two. Even back in the VB6 days (I say "back in the days" ruefully: we are still supporting the product!) I used JS for a large chunk of validation code server-side, this meant that the same logic was used in both places aside from some wrapper code to arrange for the code on both sides to be presented with the same data model. From the point of view of a relative beginner to server-side coding who is adept at Javascript on the client side this is particularly attractive (much like Python being available in browsers would be to seasoned server-side Python programmers)

The attraction of node in particular is a mixed bag:

* Momentum. People are using it so people are using it.

* The event driven nature, if properly handled, can make it very memory efficient.

* The speed of V8, which at the time was a step or two ahead of other javascript engines (since node first turned up there has been plenty of active development in this area, with a different story each month about one or the other JS engine beating everything else in some benchmark or other, so I'm not sure which has any sort of upper hand at the moment).

* It arrived at the right time, and development from "proof of concept" to a relatively mature product happened fast enough that people didn't become disillusioned soon after the initial excitement.

* Decent library support, partly due to the number of people created the above mentioned momentum. It is easy for an alternative server-side stack to suffer in this area and eventually die because of it. Though the rapid development may make this bite back a bit, as a lot of bindings from six months ago that have not been actively maintained might not work because of changes in node over that time.

* Other Javascript based server-side stacks have started to die off already, such as Jaxer (http://en.wikipedia.org/wiki/Jaxer#Aptana_Jaxer) for one example, partly due to the popularity of node.js though in many cases it was already happening (or they didn't gain much traction to start with).

link