Un amigo me mandó el titular esta semana con una sola palabra adjunta: '¿por fin?'. El equipo de Swoole ha liberado TypePHP, un compilador ahead-of-time que toma código con pinta de PHP, emite C++ y te entrega un binario nativo, y la tabla de benchmarks llega a rondar un 150x sobre el intérprete. Mi respuesta a su '¿por fin?' es no, y también sí. No, porque esto no va a hacer tu aplicación Symfony 150 veces más rápida, y los mantenedores nunca dijeron que lo haría. Sí, porque acaba de pasar algo silenciosamente importante: la barrera para escribir una extensión nativa de PHP bajó de 'apréndete la API en C de Zend' a 'ejecuta Composer'. Esa segunda historia merece el titular, y es la que quiero defender.

terminal
composer require --dev swoole/typephp
vendor/bin/tpc.php project.yml

Primero, qué es la cosa en realidad. TypePHP nació dentro de Swoole como un compilador AOT interno y fue renombrado cuando el equipo admitió lo que había construido: un lenguaje fuertemente tipado que se lee como PHP pero que nunca toca los opcodes de la ZendVM. La historia del bootstrap es el tipo de detalle que nos encanta a los frikis de compiladores. El compilador está escrito en PHP, y el binario tpc que ejecutas es el propio código fuente del compilador pasado por una versión anterior de sí mismo. Un compilador de PHP autoalojado no estaba en mi cartón de bingo de 2026, y lo digo con cariño genuino.

¿De dónde salen los números grandes? De negarse a pagar el impuesto de flexibilidad de PHP en código que nunca necesitó esa flexibilidad. El PHP de serie encapsula cada valor para que su tipo pueda cambiar en pleno vuelo, algo maravilloso cuando estás pegando una respuesta de API a una plantilla y puro sobrecoste cuando estás sumando sesenta millones de floats. Pon use native_types; al principio de un archivo TypePHP y int, float y bool se convierten en int64_t y double, así que un bucle apretado compila a aritmética de CPU pura y dura. Los arrays reciben el mismo trato: en lugar del hashmap para todo de PHP puedes echar mano de contenedores modelados sobre std::vector, std::array y std::map, tipados de antemano. Los benchmarks publicados enfrentan PHP 8.4 contra TypePHP compilado con -O3, y hasta los propios mantenedores advierten de que los resultados bailarán según tu CPU, tu compilador y tu build de PHP. Vale. Aunque dividas mentalmente cada cifra entre cinco, que un bucle numérico caliente aterrice cerca del territorio del C++ escrito a mano es otro deporte distinto de afinar opcache.

Ahora la parte en la que tengo que ser honesto contigo, porque el proyecto también lo es. TypePHP compila una rebanada definida de PHP, no PHP. El código de nivel superior de un archivo solo puede contener declaraciones, el modo de binario independiente exige un main() con firma fija, y una larga cola de trucos dinámicos, desde las variables variables hasta la mayoría de las acrobacias con reflection, se rechaza por diseño. El equipo mantiene la lista completa de negativas en docs/INCOMPATIBLE_PHP_FEATURES.md, y leer ese archivo con tu código delante es el paso uno de cualquier evaluación. Tu aplicación Laravel no va a compilar. Tus entidades de Doctrine no van a compilar. Quien te diga lo contrario no lo ha intentado.

Y aquí está el contraargumento que me tomo en serio: ya hemos visto dialectos tipados de PHP, y el recuerdo escuece. Hack bifurcó el lenguaje, atrajo a una empresa gigante a su órbita y nos dejó al resto con ejemplos de código incompatibles en Stack Overflow durante una década. Un lenguaje de subconjunto corre el riesgo de partir en dos las bibliotecas, los tutoriales y el mercado de contratación. Añade la fricción práctica: TypePHP quiere PHP 8.4 u 8.5 con cabeceras de desarrollo, GCC 9 o superior o un Clang capaz de C++17, CMake 3.24+ y la SAPI embed para compilar binarios, y además se distribuye bajo GPL-3.0, algo que tu equipo legal querrá leer antes de que distribuyas un artefacto compilado. Eso es una toolchain de verdad y una conversación de licencias de verdad, no una casilla que marcar.

Entonces, ¿por qué sigo cayendo del lado optimista? Por una sola bandera: -m ext. TypePHP puede compilar tu módulo como una extensión de PHP cargable, y una capa puente llamada PHPX permite que el mundo compilado llame y conviva con el territorio Zend normal, incluido un simple require de archivos .php corrientes. Piensa en lo que eso reemplaza. Hasta ahora, si tu puntuador de coincidencias difusas o tu normalizador de CSV se comía el 40 por ciento de la CPU de un worker, tus opciones eran reescribirlo como extensión en C, encajarle FFI o extraer el trabajo entero a un sidecar en Go y heredar un segundo despliegue. Ahora la propuesta es: quédate en sintaxis PHP, añade tipos, compila ese único archivo, carga el .so y listo. El riesgo de fragmentación se encoge mucho cuando el dialecto vive en los bordes de tu aplicación en lugar de reemplazar su núcleo.

También hay guarniciones que merecen un vistazo. Los tipos de precisión arbitraria vienen con las pilas puestas, con bigInt sobre GMP, bigFloat sobre MPFR y decimal sobre libmpdec, algo que cualquiera que haya hecho cálculos con dinero en PHP sabrá apreciar. Atributos como #[Getter] y #[Constructor] generan boilerplate tipado en tiempo de compilación. Y la lista de destinos llega más allá de Linux, macOS y Windows en x64 y ARM64 hasta WASI 0.2 y el navegador, aunque a día de hoy Linux x64 es el único camino que yo llamaría apto para producción. El número de versión, 0.6.6, ya gestiona expectativas por sí solo, y así debe ser.

Mi postura, entonces: ignora el 150x, quédate con la herramienta. TypePHP no es un PHP más rápido, es la primera toolchain de extensiones que habla nuestro idioma, y preferiría ver a la comunidad afilar ese caso de uso antes que perseguir sueños de compilar aplicaciones enteras. Pero tengo mis puntos ciegos, y la mayoría de mis rutas calientes en realidad tienen forma de SQL, así que dime: ¿cuál es ese bucle en PHP puro de tu sistema en producción que de verdad quema CPU, y le comprarías una toolchain de C++ en tu CI, o ese trabajo pertenece fuera de PHP por muy familiar que parezca la sintaxis?