[byroot]

Mike Perham (the sidekiq maintainer) also maintains the less well known faktory[0] which is language agnostic and has runners for both Ruby and Python

[0] https://github.com/contribsys/faktory

[rjzzleep]

That's awesome. Any idea why he doesn't just supersede Sidekiq with that? I spent quite some time hacking my own solution.

I just looked at the source, I guess Mike has been mostly working on both projects on his own for the last 4 years, so Faktory has a lot of features that require the enterprise license.

I wonder if he could change the situation it he markets a bit more to the python and more specifically Django community.

[ignurant]

It is pretty cool. I’ve been using it for 3-4 years as a queue between Ruby and Node for scraping tasks. Ruby queues the work, a node worker does the downloading, and a Ruby process parses and loads data. It works incredibly well in my use case and has saved me from having to shift everything to one language or the other. It’s been very reliable.

[f6v]

Because people running sidekiq with their Ruby app on production don’t care about cross-language queue. If you pay for Pro or Enterprise you don’t want any major changes that are potentially breaking.

[cactusplant7374]

The only reason we pay is because the pro version doesn't lose jobs if a worker crashes. You would think that would be a core feature.

[ckolkey]

Sounds like Mike found a good feature that would encourage companies to purchase a license. I have a tremendous admiration for the business he's built.

[cactusplant7374]

You would think not losing jobs would be a required feature in any job queue software product.

[f6v]

> You would think not losing jobs would be a required feature in any job queue software product.

A free software doesn’t have to be anything because it’s free.

[aaronbrethorst]

A man’s gotta eat.

[keithalewis]

This relies on the Go runtime scheduler. Sometimes that is not good enough.