Celery, non-blocking code and quest against coroutines
The TL;DR (tl;dr: this explains how Celery obsoletes GIL and coroutines) is only telling half of the story.<p>Celery solves some cases for Python:<p>- background tasks;
- tasks queues;
- cron tasks.<p>And it&#x27;s nice, I used it extensively. But in NO WAY it totally solves the GIL problem nor does it render coroutines obsolete.<p>Here are some celery limits:<p>- you need to calibrate the number of worker you have to match your workload.<p>- You are limited to x number of blocking operations, where x is the number of workers. It means you cannot do massively parallel I&#x2F;O such as network operations with it (e.g: a web server).<p>- Tasks don&#x27;t have access to your main process memory, and vice versa.<p>- Tasks cannot communicate with each others;<p>- You must juggle with the workflow of your tasks (is it ready ? it it dead ?). You can use await stuff() with a try&#x2F;except;<p>- Celery is an additional process to setup and start, with backends to choose from and tuning to do. It&#x27;s a lot more work than just importing an async lib.<p>Granted, celery is a very useful piece of software, but not the silver bullet this article depicts.