Pongo mis cartas sobre la mesa: creo que la decisión de True Async de prescindir por completo de las funciones coloreadas es la mejor llamada de diseño que alguien ha hecho jamás para la concurrencia en PHP, y prefiero que se le escape el tren de PHP 8.6 antes que verlo llegar con ese principio comprometido. El proyecto — actualmente en v0.8.4 y etiquetado con honestidad como un core experimental — aparece en php.watch con PHP 8.6 como objetivo, y la hoja de ruta apunta a una v1.0 estable en noviembre de 2026, justo al lado del lanzamiento de 8.6 programado para el 19 de noviembre. La Alpha 1 salió el 2 de julio, la Beta 1 está prevista para mediados de agosto. Así que el reloj corre de verdad. Pero la pregunta que quiero discutir no es si llega a tiempo. Es si entendemos en qué nos estamos metiendo.

Primero, por qué el diseño sin colores importa tanto precisamente para nosotros. En JavaScript o Python, en cuanto una función es async, todo lo que la llama tiene que volverse async también, y la división trepa por tu código como la humedad por una pared. True Async dice: sin keyword, sin anotación, sin reescritura. Envuelves código normal en spawn(), y dentro de esa corrutina, más de 70 funciones estándar — file_get_contents, fread, curl_exec, PDO contra MySQL y PostgreSQL, socket_read, incluso sleep() — se vuelven silenciosamente no bloqueantes. Fuera de una corrutina se comportan exactamente como siempre. Para un lenguaje con veinticinco años de librerías síncronas en Packagist, eso no es una comodidad. Es la única ruta de migración que no exige reescribir el ecosistema.

Y la ingeniería que hay debajo es más seria que la típica prueba de concepto. El pooling de conexiones para PDO viene integrado, para que dos corrutinas no pisoteen en silencio el mismo handle de base de datos. flock(), que es una syscall genuinamente bloqueante, se delega a un pool de hilos para que el resto de tus corrutinas sigan avanzando mientras una espera un lock. Hay spawn_thread() para paralelismo real de CPU, y — esto me hizo incorporarme en la silla — un servidor HTTP/1.1, HTTP/2 y HTTP/3 escrito en C, corriendo dentro del proceso de PHP, sin reverse proxy delante. Los buffers de salida están aislados por corrutina. Alguien pensó en los modos de fallo aburridos, y en el trabajo de concurrencia los modos de fallo aburridos son todo el trabajo.

Ahora el contraargumento honesto, porque es potente. Las funciones coloreadas son molestas, pero lo son como es molesta una alarma de incendios: el keyword async te dice, en el punto de llamada, que esa línea puede ceder el control, que el mundo puede haber cambiado bajo tus pies cuando regrese. La transparencia de True Async borra esa señal. Una propiedad estática, un singleton memoizado, un binding del contenedor de Laravel que asume que una petición equivale a un universo aislado — todo eso era seguro porque el modelo shared-nothing de PHP lo hacía seguro. Ejecuta el mismo código en corrutinas cooperativas dentro de un solo proceso y esas suposiciones se convierten en condiciones de carrera que no puedes ver en el diff, porque el diff son tres llamadas a spawn() y nada más. Justo lo que hace fácil la adopción hace invisible la nueva clase de bugs.

Aun así me quedo del lado sin colores, y este es el porqué: la alternativa no es un PHP más seguro, es un PHP bifurcado. Ese experimento ya lo hemos hecho. AMPHP, ReactPHP y Swoole son excelentes, y cada uno construyó un universo paralelo de drivers y clientes porque la librería estándar no podía cooperar. Un core coloreado habría bendecido esa segmentación para siempre — un PDO async y un PDO síncrono, un Guzzle async y otro síncrono, mantenimiento duplicado hasta el fondo. La transparencia a nivel del motor, donde el core de Zend, la capa de I/O y la capa de sockets se modifican directamente, es la única versión de esto en la que el ecosistema converge en lugar de partirse. Los bugs de concurrencia son un precio real. El apartheid de librerías es uno mayor.

Lo que eso significa en la práctica: la carga pasa de la sintaxis a la disciplina, y al tooling. El mecanismo de Scope — concurrencia estructurada donde un grupo de corrutinas vive y muere junto, con una cancelación diseñada para no dejar datos escritos a medias — es hacia donde señalaría ahora mismo a cada autor de frameworks, porque los scopes son la forma de volver a hacer visibles los ciclos de vida cuando los keywords han desaparecido. El paquete true-async/ide-helper (una instalación --dev de Composer) ya le da a PhpStorm, PHPStan y Psalm stubs correctos para spawn() y await(), y sospecho que el análisis estático acabará haciendo el trabajo que el keyword async hace en otros lenguajes: señalar estado mutable compartido que cruza un punto de suspensión. Si quieres trastear con todo esto tú mismo, la extensión se instala en PHP 8.5+ vía su instalador o una imagen de Docker — experimental, no para producción, pero perfectamente ejecutable.

Entonces, ¿llegará a 8.6? Nadie puede prometerlo, y sinceramente prefiero esperar un ciclo antes que recibir una API de core apresurada que tendremos que soportar durante una década — los huecos que quedan, como las operaciones de directorios y los drivers PDO de Oracle y SQLite, son del tipo pequeño, pero las APIs de core son para siempre. Mi pregunta para ti es la que yo mismo no dejo de darle vueltas: cuando el ciclo de vida de peticiones de tu framework empiece a ejecutarse como corrutinas en un solo proceso, ¿cuál es la primera suposición de tu propio código que se rompe? Yo tengo una lista corta para el mío, y ninguna de las entradas me deja bien. Cuéntame la tuya.