Live data from Hacker News

Node.js - A Giant Step Backwards

fenn.posterous.com

61–70 of 117 posts

Re: Node.js - A Giant Step Backwards

#61

Just curious, is there a good futures library for Node? If so, you could write code of the form: x = db.getFutureResult("x"); y = db.getFutureResult("y"); whenFuturesReady([x,y], callback(x, y) { useResults(x,y); }); This looks reasonably similar to typical synchronous code, x = db.getResult("x") y = db.getResult("y") useResults(x,y) but it allows db queries to happen simultaneously and doesn't break the node paradig…

It never became production ready, but I found this article an interesting discussion of the problem and a solution to it in Coffeescript:

http://gfxmonk.net/2010/07/04/defer-taming-asynchronous-java...

Re: Node.js - A Giant Step Backwards

#62

Nitpick: Node doesn't do anything in parallel, it can't, it does things concurrently.

But, um, concurrently means "at the same time," too. Merriam's first definition is actually "running parallel." Wouldn't it be better to describe it as running serially, using non-blocking asynchronous function calls? Guess that doesn't really roll of the tongue, though.

then Merriam is wrong. concurrency is not parallelism

concurrency is a design consideration that provides for resource isolation.

parallelism is about algorithms designed to be executed on parallel architectures

google it, there are dozens of informative discussions

Re: Node.js - A Giant Step Backwards

#63

Earlier quoted context omitted.

Only the minority gives a shit how many Hello World requests your stack can pump out. Some of us use node.js because it's a) got some decent libraries, b) makes realtime easy, c) uses the same code server+client-side reducing context-switches, and d) gets quite enjoyable once you know what you're doing. You obviously haven't written a lot of async code so not sure why you're so against the idea.

So again, to you, what benefit does everything being built on this async, single-threaded, event-driven model give you? Sounds like not much. You could get all of those benefits + much cleaner code using threading or fibers or actors, but that does not make for C10K badassness, so here we are, with our callbacks. Also, I'd say I've written enough code on top of node.js to be qualified to comment on this. Here's some…

I get simple scalability, server-client code reuse, easy realtime, and, despite what you or others may think, I like Javascript as a language. Node.JS was also a perfect fit for the scraping framework I wrote: https://github.com/chriso/node.io

At one stage I had the same train of thought that you have (http://chris6f.com/synchronous-nodejs / https://github.com/chriso/synchronous/blob/master/lib/protot...) - it would be nice to have the option of fibers, but it's not going to happen.

IMO async code isn't as difficult or ugly as you make it out to be. Is async code as easy to write and follow as sync code? No. Is it worth the benefits I've mentioned? For me, yes.

Re: Node.js - A Giant Step Backwards

#64

Earlier quoted context omitted.

I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?

Only the minority gives a shit how many Hello World requests your stack can pump out. Some of us use node.js because it's a) got some decent libraries, b) makes realtime easy, c) uses the same code server+client-side reducing context-switches, and d) gets quite enjoyable once you know what you're doing. You obviously haven't written a lot of async code so not sure why you're so against the idea.

node.js has nothing to do with "real-time"

Re: Node.js - A Giant Step Backwards

#65

Earlier quoted context omitted.

"deal with it" is a good response. personally, I'd rather write callbacks than deal with threads any day. And there are plenty of approaches to make dealing with callbacks easier (async.js is one of many).

Actually, "deal with it" is fucking lame, isn't a response at all, and is a good example of why I use the term "fundamentalism." Is your problem with threads or shared mutable state? Web applications should be stateless and can be written as long request-response pipelines on-top of a pool of actor threads, with the only shared state existing at either ends of the pipeline, probably hidden by a framework anyways.

The "deal with it" is the same for threads - if you're using a system with threads you have to deal with them and it's generally not too fun. Node is what it is. It's callback based. I didn't mean the "deal with it" in a hostile way, more like that's the kind of system node is so deal with it. Is node great for every kind of problem? No. Definitely not. Actors are great too (and they've usually got threads in them, but they are well contained). But for certain kinds of apps node and the careful use of callbacks work out great. I guess I was trying to counter all of the hating on callbacks - they're not so awful when you get used to them.

Re: Node.js - A Giant Step Backwards

#67
post #27
post #25

Earlier quoted context omitted.

Sounds like you're about a month ahead of me. For what it's worth I also think that my very similar idea is genuinely new— best of luck!

If you're not feeling too proprietary, hit me up on twitter. Might be some areas where we can collaborate. Either way, good luck with your project as well. I tried to not do this myself, I really did. :-)

I don't use Twitter much, but I'll definitely take you up on that when I have something a little more developed. I'm coming at this from the exact opposite direction as you (what I'm doing is closer to porting Erlang to Node than vice versa), but we're obviously thinking along the same lines— I'd love to compare notes.

Re: Node.js - A Giant Step Backwards

#68

Earlier quoted context omitted.

the thinking that async code == callback spaghetti shit has to stop. There are plenty of async idioms that make callbacks a breeze.

I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?

If I can run one app with 10,000+ concurrent requests on one server, then I can run a hundred apps with a hundred concurrent requests each on that same server. You can say that doesn't matter either, but the cost of hosting a web app just dropped 99%.

Re: Node.js - A Giant Step Backwards

#69
It seems a bit cruel that he mentions "horror stories" about Twisted; most of the culture shock people complain about with Twisted is exactly the kind of flow-control shenanigans that he describes in Node.js. In fact, Twisted makes those particular examples easier.

To handle branching flow-control like 'if' statements, Twisted gives you the Deferred object[1], which is basically a data structure that represents what your call stack would look like in a synchronous environment. For example, his example would look something like this, with a hypothetical JS port:

    d = asynchronousCache.get("id:3244"); // returns a Deferred
    d.addCallback(function (result) {
	if (result == null) {
	    return asynchronousDB.query("SELECT * from something WHERE id = 3244");
	} else {
	    return result;
	}
    });
    d.addCallback(function (result) {
	// Do various stuff with myThing here
    });
Not quite as elegant as the original synchronous version, but much tidier than banging raw callbacks together - and more composable. Deferred also has a .addErrback() method that corresponds to try/catch in synchronous code, so asynchronous error-handling is just as easy.

For the second issue raised, about asynchronous behaviour in loops, Twisted supplies the DeferredList - if you give it a list (an Array, in JS) of Deferreds, it will call your callback function when all of them have either produced a result or raised an exception - and give you the results in the same order as the original list you passed in.

It is a source of endless frustration to me that despite Twisted having an excellent abstraction for dealing with asynchronous control-flow (one that would be even better with JavaScript's ability to support multi-statement lambda functions), JavaScript frameworks generally continue to struggle along with raw callbacks. Even the frameworks that do support some kind of Deferred or Promise object generally miss some of the finer details. For example, jQuery's Deferred is inferior to Twisted's Deferred: http://article.gmane.org/gmane.comp.python.twisted/22891

[1]: http://twistedmatrix.com/documents/current/core/howto/defer....

Re: Node.js - A Giant Step Backwards

#70

It seems a bit cruel that he mentions "horror stories" about Twisted; most of the culture shock people complain about with Twisted is exactly the kind of flow-control shenanigans that he describes in Node.js. In fact, Twisted makes those particular examples easier. To handle branching flow-control like 'if' statements, Twisted gives you the Deferred object[1], which is basically a data structure that represents what…

Here's a library in JavaSCript that does this. https://github.com/kriszyp/promised-io

The differences between your example and the common JavaScript practice for promises (when they're used; most of the time they aren't) are that then is used instead of addCallback and that chaining is available and taken advantage of.

Post reply on HN