> They even suggest asyncio could be a replacement for celery... It really is the Wild West out here.
Yeah this is pretty questionable.
Having state in your app's process and then having to pretty much re-invent queues, job cancellation, uniqueness guarantees, scheduled jobs, periodic jobs on an interval, queue draining and retries with exponential backoffs.
I mean, yeah you could code all of that with enough time but why would you when Celery exists. If anything having the queue's state held in Redis or anywhere outside of your app's process is enough of a reason to pretty much never replace Celery with asyncio. Even in the post's example of sending an email I would still want a lot of what Celery has to offer and wouldn't consider replacing it.
IMO Celery isn't going anywhere soon and I would still use it in every Python project that needs background processing.
Just based on my C# experience, this sounds like a terrible idea (abandoning a real task queue for Async/await). 90% of the “gotchas” with async/await in C# comes from people thinking that the task scheduler is bonafide background queue.
Yeah this is pretty questionable.
Having state in your app's process and then having to pretty much re-invent queues, job cancellation, uniqueness guarantees, scheduled jobs, periodic jobs on an interval, queue draining and retries with exponential backoffs.
I mean, yeah you could code all of that with enough time but why would you when Celery exists. If anything having the queue's state held in Redis or anywhere outside of your app's process is enough of a reason to pretty much never replace Celery with asyncio. Even in the post's example of sending an email I would still want a lot of what Celery has to offer and wouldn't consider replacing it.
IMO Celery isn't going anywhere soon and I would still use it in every Python project that needs background processing.