await no significa 'mentrestant': el bug de JS a Python

Quan un equip de desenvolupament amb experiència en JavaScript aborda Python asíncron per primera vegada, sol repetir un patró que sembla inofensiu: llançar diverses tasques una rere l'altra i esperar els seus resultats amb await. A JavaScript, la crida a una funció asíncrona dispara l'execució de manera immediata, i el await posterior simplement recull el resultat d'un procés que ja estava corrent. Aquest 'crida d'hora, espera tard' és un truc elegant per paral·lelitzar operacions d'entrada/sortida sense usar Promise.all. No obstant, en traslladar aquest mateix codi a Python, el comportament canvia de forma silenciosa: la crida a una funció async def no arrenca res, només crea un objecte coroutine inert. El primer await executa la primera rutina completa, i només llavors arrenca la segona. El resultat és un programa que funciona correctament però que seqüencialitza tasques que podrien haver-se executat en paral·lel, duplicant la latència total. És un bug de rendiment que no genera errors, no salta en logs i es camufla sota la sospita que 'Python és lent'. A Q2BSTUDIO, en desenvolupar aplicacions a mida per a entorns multicloud, hem vist aquest patró repetir-se en equips que migren de Node.js a frameworks com FastAPI o Django Channels. La solució passa per entendre que Python ofereix un model diferit: la concurrència real s'aconsegueix embolicant les corutines en tasques amb asyncio.create_task o usant asyncio.gather i TaskGroup. Aquestes construccions sí que llancen l'execució de manera immediata, emulant la semàntica eager de JavaScript. La clau està a canviar la lectura mental de await: a Python ja no és un punt de recollida d'un treball que ja avança, sinó el lloc on el treball ocorre. Aquest matís té implicacions profundes en l'arquitectura de sistemes que integren serveis cloud aws i azure, on cada mil·lisegon de latència suma en costos d'infraestructura i experiència d'usuari. La decisió de Python de fer les corutines pereses no és un caprici; ve de la seva herència amb els generadors i d'una postura de disseny que evita el treball implícit en segon pla. Mentre JavaScript llança promeses en crear-les i després ha de gestionar rebutjos no capturats, Python obliga el desenvolupador a ser explícit sobre quines tasques s'executen concurrentment. Això encaixa amb un enfocament de ciberseguretat i control de recursos: res no s'executa sense supervisió. Per a equips que construeixen ia per a empreses o agents IA que requereixen múltiples consultes a APIs, bases de dades o models de llenguatge, dominar aquest patró pot reduir temps de resposta de centenars de mil·lisegons a uns pocs. El mateix passa en processos de intel·ligència de negoci amb power bi, on la ingesta de dades des de fonts distribuïdes es beneficia d'una concurrència ben gestionada. A Q2BSTUDIO apliquem aquestes bones pràctiques a cada projecte de programari a mida, combinant serveis intel·ligència de negoci amb arquitectures asíncrones per oferir productes escalables i ràpids. El veritable aprenentatge és que la familiaritat amb un llenguatge no garanteix que els seus patrons es transfereixin a un altre; cal entendre els fonaments de cada runtime. I quan l'objectiu és esprémer el màxim rendiment sense sacrificar claredat, eines com TaskGroup (disponible des de Python 3.11) es converteixen en aliades indispensables. Així, l'error del programador de JavaScript es transforma en una oportunitat per dissenyar sistemes més robustos, on cada tasca concurrent té un cicle de vida explícit i controlat.