3 ms·
Full disclosure, the author sounds like an arrogant ass and I couldn't stomach the full article... But I find that queues are often misunderstood/misused. You
by flaminHotSpeedo 3y ago
Full disclosure, the author sounds like an arrogant ass and I couldn't stomach the full article...
But I find that queues are often misunderstood/misused. You have to be careful not to use them in systems where the producer cares about the output (true story - I've had someone earnestly suggest an "ack queue," essentially implementing TCP-over-SQS), you absolutely cannot use them in latency sensitive contexts (if you need an async job pool, use a stack. Your peak load customers will thank you), and you have to be careful about idempotency, ordering, and delivery guarantees.
Also to put on my own arrogant hat, most of the time I've seen linked queues it's been better to orchestrate the system as a state machine.
- hinkley 3y agoI have coworkers debating how to automatically update half a hundred build scripts to pick up new runtime versions. I’ve long, long since given up getting the, to realize that separate build plans are only accomplishing one thing: Enabling (as in codependency) a bunch of bad, slow tests in two sections of the code to persist instead of needing to be rewritten. This project has no proper reason to be more than a dozen modules, and we’ve spent time on tooling to reduce the burden of managing so many repos at once. If you don’t have a small mountain of builds you have to compose, you don’t have the queuing problems that go along with them.
- victorNicollet 3y agoWhat kind of situation would have a producer push into a queue but not care about the output ? The only one I could come up with, is doing some computation in advance that would otherwise need to be done just-in-time when the result is requested later.