4 ms·

> 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 har

> 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 15y ago
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 15y ago
  What's his critique of queues?
  - deleted 15y ago
    [deleted]
  - BarkMore 15y ago
    http://teddziuba.com/2011/02/the-case-against-queues.html http://teddziuba.com/2011/02/the-case-against-queues.html
  - mhd 15y ago
    It's here: http://teddziuba.com/2011/02/the-case-against-queues.html 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 15y ago
      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 15y ago
      He seems to argue against having a blocking worker wait for the queue, which is exactly what you wouldn't do with Node.js

jrockway 15y ago

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 15y ago
What's his critique of queues?
- deleted 15y ago
  [deleted]
- BarkMore 15y ago
  http://teddziuba.com/2011/02/the-case-against-queues.html http://teddziuba.com/2011/02/the-case-against-queues.html
- mhd 15y ago
  It's here: http://teddziuba.com/2011/02/the-case-against-queues.html 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 15y ago
    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 15y ago
    He seems to argue against having a blocking worker wait for the queue, which is exactly what you wouldn't do with Node.js