await no significa 'mientras tanto': el bug de JS en Python

Cuando un equipo de desarrollo con experiencia en JavaScript aborda Python asíncrono por primera vez, suele repetir un patrón que parece inofensivo: lanzar varias tareas una tras otra y esperar sus resultados con await. En JavaScript, la llamada a una función asíncrona dispara la ejecución de inmediato, y el await posterior simplemente recoge el resultado de un proceso que ya estaba corriendo. Ese 'llama temprano, espera tarde' es un truco elegante para paralelizar operaciones de entrada/salida sin usar Promise.all. Sin embargo, al trasladar ese mismo código a Python, el comportamiento cambia de forma silenciosa: la llamada a una función async def no arranca nada, solo crea un objeto coroutine inerte. El primer await ejecuta la primera rutina completa, y solo entonces arranca la segunda. El resultado es un programa que funciona correctamente pero que secuencializa tareas que podrían haberse ejecutado en paralelo, duplicando la latencia total. Es un bug de rendimiento que no genera errores, no salta en logs y se camufla bajo la sospecha de que 'Python es lento'. En Q2BSTUDIO, al desarrollar aplicaciones a medida para entornos multicloud, hemos visto este patrón repetirse en equipos que migran de Node.js a frameworks como FastAPI o Django Channels. La solución pasa por entender que Python ofrece un modelo diferido: la concurrencia real se consigue envolviendo las corutinas en tareas con asyncio.create_task o usando asyncio.gather y TaskGroup. Estas construcciones sí lanzan la ejecución de inmediato, emulando la semántica eager de JavaScript. La clave está en cambiar la lectura mental de await: en Python ya no es un punto de recolección de un trabajo que ya avanza, sino el lugar donde el trabajo ocurre. Este matiz tiene implicaciones profundas en la arquitectura de sistemas que integran servicios cloud aws y azure, donde cada milisegundo de latencia suma en costes de infraestructura y experiencia de usuario. La decisión de Python de hacer las corutinas perezosas no es un capricho; viene de su herencia con los generadores y de una postura de diseño que evita el trabajo implícito en segundo plano. Mientras JavaScript lanza promesas al crearlas y luego debe gestionar rechazos no capturados, Python obliga al desarrollador a ser explícito sobre qué tareas se ejecutan concurrentemente. Esto encaja con un enfoque de ciberseguridad y control de recursos: nada se ejecuta sin supervisión. Para equipos que construyen ia para empresas o agentes IA que requieren múltiples consultas a APIs, bases de datos o modelos de lenguaje, dominar este patrón puede reducir tiempos de respuesta de cientos de milisegundos a unos pocos. Lo mismo ocurre en procesos de inteligencia de negocio con power bi, donde la ingesta de datos desde fuentes distribuidas se beneficia de una concurrencia bien gestionada. En Q2BSTUDIO aplicamos estas buenas prácticas en cada proyecto de software a medida, combinando servicios inteligencia de negocio con arquitecturas asíncronas para ofrecer productos escalables y rápidos. El verdadero aprendizaje es que la familiaridad con un lenguaje no garantiza que sus patrones se transfieran a otro; hay que entender los fundamentos de cada runtime. Y cuando el objetivo es exprimir el máximo rendimiento sin sacrificar claridad, herramientas como TaskGroup (disponible desde Python 3.11) se convierten en aliadas indispensables. Así, el error del programador de JavaScript se transforma en una oportunidad para diseñar sistemas más robustos, donde cada tarea concurrente tiene un ciclo de vida explícito y controlado.