[politician]

> Am I the only one that puts computationally intensive tasks into a queue to be taken care of by a pool of seperate processes?

Thank you. I really find it hard to believe that the reaction to Ted's post was to mess around with Fib implementations rather than to just say, "use a background queue," and move on.

If Ted has a point at all, it could be that he thinks that people using nodejs don't realize they're running in a loop. Maybe that's fair.

[jrockway]

Ted hates queues, too.

But I don't, so instead of playing tough-guy and picking on random open source communities that don't want me, I get to write cool computer programs. Maybe we should all do the same.

[grandalf]

What's his critique of queues?

[mhd]

It's here: http://teddziuba.com/2011/02/the-case-against-queues.html

TL;DR - It's not so much about queues, but about stacks, i.e. new software stacks. His proposition is that quite often you're better off with existing systems. He specifically mentions syslog, so you're logging your tasks and then the consumers monitor this log. Prevents data loss and lets you potentially restart lost tasks.

(That's his argument. I'd agree if you'd have to reimplement something like that in the pre-built *MQ solutions, but I don't know enough about all of them, maybe that – and more – is already in there.)

[grandalf]

Interesting. I actually agree with his points (they are consistent with lessons I've learned overusing queues in the past).

I still use queues today, only more judiciously and with the issue of failure states a very well defined part of the design.

[Tichy]

He seems to argue against having a blocking worker wait for the queue, which is exactly what you wouldn't do with Node.js