by skazka16 on 5/22/15, 1:48 AM with 56 comments
by onestone on 5/22/15, 10:24 AM
- It implies that async execution is equivalent to callback hell. In reality there are excellent ways to have async code which looks just like sync (generators, async/await).
- It benchmarks multi-core (sync) vs single-core (async) and makes claims based on the results.
- It presents async execution as an antipode of clustering. In reality it's a best practice to make use of both.
...and everything that follows is just irrelevant.
by eldude on 5/22/15, 7:20 AM
Request per-process/thread has all the same memory overhead implication it has always had. It's almost like the author is ignorant of the reason for node.js' success or why it was built in the first place.
Also, "callback hell" is just FUD. Nobody who does this for a living and knows what they're doing really has an issue with this. Promises solve the unreliability issues, and async/await solves the syntax complexity issues.
I'd like to see this same analysis for 1000 req concurrency measuring memory overhead and using async/await for code comparison. Cooperative multitasking will always be capable of lower latency when you know what you're doing, and async programming is lightyears simpler than multi-threaded programming.
by kellros on 5/22/15, 10:30 AM
We've been running a Koa.js API server using Cluster in production for over a year now with no hiccups (on a Windows machine).
I've been thinking about making the switch to iisnode, as it handles clustering, graceful shutdown and zero-downtime from within IIS (and does a couple of other things). It uses named pipes to proxy connections and also supports web sockets among other things.
With the nodeProcessCommandLine configuration setting, you can pass parameters to node (e.g. --harmony), use babel-node or io.js.
See: http://www.hanselman.com/blog/InstallingAndRunningNodejsAppl...
A blog post I wrote a while ago: https://shelakel.co.za/hosting-almost-any-application-on-iis...
by crueber on 5/22/15, 1:37 PM
If this had compared Node.js with clustering and async vs a synchronous language like Ruby, it might have been interesting. Maybe. But non-asynchronous operations in Node are an antipattern that core node contribs are trying to remove (the -Sync in node stdlib are trying to be removed).
Good coding conventions, promises, generators, and async/await are your friends for making callback hell go away.
by bungle on 5/22/15, 7:13 AM
At Nginx conf the Nginx developers where showing interest to bring Javascript to the platform. They said that they will take similar approach that OpenResty uses (aka no callback hell).
by pmalynin on 5/22/15, 6:42 AM
Instead of taking a callback, a function returns a promise, which can be daisy-chained to do work.
Ex:
file.read().then(console.log);
Or using the example in the article:
var a = fileA.read();
var b = fileB.read();
promise.all([a,b]).then((data) => console.log(data[0], data[1]));
by DonPellegrino on 5/22/15, 1:08 PM
by bhouston on 5/22/15, 8:23 AM
Also Sync versions of calls in NodeJS are likely going to be deprecated, thus this won't even be possible in NodeJS going forward.
by zjonsson on 5/22/15, 12:40 PM
by andrewmutz on 5/22/15, 6:24 AM
OS-level multitasking won't be able to achieve the same level of concurrency, but the simplicity and maintainability of the application will go up. The right choice depends on the needs of the application, of course.
Both evented and non-evented approaches have their place, and most server-side languages allow development with either approach: Ruby, Python, C, Java all have solid options for evented and non-evented solutions.
by martin-adams on 5/22/15, 10:34 AM
Code looks like this:
var sync = require('./sync');
sync(function () {
try {
var result = someAsyncFunc1.callSync(this, 'param1', param2');
if (result.something === true) {
var result2 = someAsyncFunc2.callSync(this, 'param1');
} else {
var result2 = someAsyncFunc3.callSync(this, 'param1');
}
console.log(result2.message);
} catch (ex) {
// One of them returned an err param in their callback
}
});
by babby on 5/22/15, 7:26 AM
The more annoying con is lack of shared memory. A single process can be much less complex when it doesn't have to worry about messaging systems and off process caching.
by bcoates on 5/22/15, 8:51 AM
The only real competition is transactional memory but it hasn't become mainstream yet.
by tlrobinson on 5/22/15, 8:04 AM
I'd argue the root cause is... callbacks.
Asynchronous programming can be done elegantly, in a synchronous style using "async/await", originally (?) in C# [1], likely to be added to the next version of JavaScript [2], also in Dart [2], Hack [4], and Python 3.5 [5]. It can also be emulated in languages with coroutines/generators [6][7][8] (which in turn can be implemented by a fairly simple transpiler [9][10])
This:
function foo(a, callback) {
bar(a, function(err, b) {
if (err) {
callback(err)
} else {
baz(b, function(err, c) {
if (err) {
callback(err)
} else {
// some more stuff
callback(null, d)
}
})
}
})
}
async function foo() {
var a = await bar(a)
var c = await baz(b)
// some more stuff
return d;
}
[1] https://msdn.microsoft.com/en-us/library/hh191443.aspx
[2] http://jakearchibald.com/2014/es7-async-functions/
[3] https://www.dartlang.org/articles/await-async/
[4] http://docs.hhvm.com/manual/en/hack.async.asyncawait.php
[5] https://lwn.net/Articles/643786/
[6] https://github.com/petkaantonov/bluebird/blob/master/API.md#...
[7] https://github.com/kriskowal/q/tree/v1/examples/async-genera...
by meritt on 5/22/15, 6:40 AM
by KaiserPro on 5/22/15, 9:11 AM
I understand that because if the funny scoping rules it means that threading is actually surprisingly hard? surely you'd want more control over your threaded event loops?
by igl on 5/22/15, 10:17 AM
by bricss on 5/22/15, 8:48 AM