Hacker News Reader

Comment by dorianmariefr | Hacker News Reader

Delayed Job seems to have been abandoned, a better alternative that is a fork with many improvements is https://github.com/betterment/delayed

View on HN

Yes sorry, please use betterment's fork. I got busy with other projects since writing delayed_job and had to prioritize.

like running one of the top 100 companies in the world :) thanks for everything

Consider adding this to the top of the README of delayed_job?

I helped maintain delayed_job_web as a UI. It has fallen behind substantially now though. If folks are looking for a UI - it would be great to update it for modern versions of Rails. https://github.com/ejschmitt/delayed_job_web

very cool! thank you

Seems maintained to me:

https://rubygems.org/gems/delayed_job

https://github.com/collectiveidea/delayed_job

    > 4.1.10 - January 18, 2022 (40 KB)
    > 4.1.9 - December 09, 2020 (40 KB)

Ok last I checked it was before January and I wanted to upgrade to rails 7 and couldn't so ended up moving to Sidekiq

Rails 7 support only just got added https://github.com/collectiveidea/delayed_job/pull/1161

Sets a bad precedent, I'm on rails's main branch and this was the big dependency holding me back for a while. Sidekiq works with rails's main though

https://github.com/que-rb/que

This one seems to be the most performant. By a lot too, from my understanding (haven't ran any benchmark myself, but the readme shows some good postgres knowledge)

One big difference if you're changing forks is to take note of "at least once delivery": https://github.com/betterment/delayed#at-least-once-delivery

If you're not aware of that, simply switching repos may cause some surprises.

Just to note that at least once delivery is the best case scenario if you configure Delayed::Job correctly, we just made it impossible to configure otherwise in our fork. The only alternative is at-most-once delivery, which puts you in Sidekiq territory with the potential for silent job loss. The semantics of exactly once delivery can only be achieved by domain-aware code, and the way to do that with any form of background job system is building jobs that are internally idempotent.

Another fork is [0], which adds debouncing, serialization, recurring jobs, and other useful things.

(Disclaimer: I used to work at Instructure.)

[0] https://github.com/instructure/inst-jobs

Reply on news.ycombinator.com