--- title: "PHP não precisa de um PHP mais rápido" description: "TypePHP promete acelerar PHP e Whim admite que não é PHP. Eu preferia generics apagados mas entendo por que o internals disse não." pubDate: 2026-09-10T00:00:00.000Z author: "Brimmar" lang: "pt-BR" canonicalUrl: "https://brimmar.dev/blog/php-nao-precisa-de-um-php-mais-rapido/" tags: ["php", "whim", "typephp", "generics"] --- # PHP não precisa de um PHP mais rápido Eu aprendi a programar em C. Quando você vem de C você tipa tudo por reflexo e estranha quando a linguagem deixa passar qualquer coisa. Foi por isso que nunca me acostumei com PHP sem tipos. Eu passo tempo demais escrevendo guardrail, checando o que entrou, o que saiu, tentando adivinhar o que vai quebrar em produção porque veio um tipo que eu não esperava. Nos últimos meses eu mantive bibliotecas onde o PHPStan faz o trabalho que eu queria que o engine fizesse. Funciona, mas é um imposto. ## O imposto do comentário Se você usa PHPStan ou Psalm hoje, você já usa generics. Só que dentro de comentário. A docblock mente que é documentação e o analisador finge que é código. ```php /** * @template T * @param Collection $items * @return T */ function first(Collection $items) { /* ... */ } ``` São mais de 202 mil arquivos no GitHub usando esse truque. É o que o [Brent Roose chamou de comment tax](https://stitcher.io/blog/generics-in-php-3). A [RFC de Bound-Erased Generic Types](https://wiki.php.net/rfc/bound_erased_generic_types) do Seifeddine Gmati propunha só tirar isso do comentário e colocar na sintaxe. `Box` e `Box` seriam a mesma classe em runtime, o tipo viraria o bound declarado, sem custo em prod, com segurança em dev. O motor veria `mixed` ou o bound, o Reflection guardaria a forma original para a ferramenta ler. É o modelo apagado, igual Java faz. Eu preferia que tivesse passado. Era o que fazia mais sentido para mim, e vai na linha do que o PHP Annotated já defendeu, checar tudo em análise e rodar sem checagem extra em produção. O próprio Brent defendeu isso em 2021 no texto [We don't need runtime type checks](https://stitcher.io/blog/we-dont-need-runtime-type-checks) e de novo na série de quatro posts sobre [por que não temos generics no PHP](https://stitcher.io/blog/generics-in-php-3). A [PHP Foundation também mapeou as alternativas em State of Generics and Collections](https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections) e admitiu que reificado é muito mais caro em um interpretado. > Erased generics as proposed are a direct continuation on this path, which is already proved viable and useful. Thanks to IDEs, static analysis in PHP has a much wider user-base than just the active users of phpstan, psalm, et al. > — Nicolas Grekas, citado em [A generic tragedy](https://tempestphp.com/blog/a-generic-tragedy) Só que eu entendo por que não passou. A RFC foi declinada em maio e a Fundação já tinha sinalizado a preferência por outro caminho em [Compile time generics yay or nay](https://thephp.foundation/blog/2025/08/05/compile-generics). O PHP escolheu faz tempo que tipo é checado em runtime. Quando você escreve `function add(int $a)` o engine converte ou joga TypeError na hora. É assim que a linguagem pensa. Colocar generics que somem seria criar duas regras na mesma casa. Um tipo que checa em runtime e outro que some. Parece detalhe, mas linguagem incoerente cobra juros por anos. Quem mantém algo que roda boa parte da web não pode experimentar rápido. Como o Nuno bem colocou, o internals move devagar por um motivo.

PHP Annotated sobre generics no PHP e a proposta de bound-erased generics. Veja a RFC completa.

## TypePHP, o binário que não é PHP É dessa frustração que nasce o [TypePHP](https://github.com/swoole/typephp), o antigo Swoole AOT rebatizado. Ele pega PHP 8.4 ou 8.5, baixa para C++17 e gera binário nativo. O site mostra fib(40) 135 vezes mais rápido que ZendVM e PI 69 vezes. Esses números são reais e contam metade da história. Quando você roda `bench.php` e `micro_bench.php` do próprio php-src o ganho cai para oito vezes e seis vezes e meia. Ainda é bom, mas é computação pura. Aplicação web típica não vive de Fibonacci. O projeto impressiona por outro motivo. Ele é escrito em PHP e se compila, é self-hosting de verdade, e tem três modos, binário, extensão e lib compartilhada. Só que ele não é drop-in. A [lista de incompatibilidades](https://github.com/swoole/typephp/blob/master/docs/en/INCOMPATIBLE_PHP_FEATURES.md) tem quase duzentas linhas. Escopo global só pode declarar, código tem que estar em função com `main()`, `$$` não existe, closure não pode ser rebindada, `union` ainda vira `mixed` no C++ gerado, propriedade com tipo nativo não pode mudar de tipo depois. O próprio README avisa que é um subconjunto definido e testável. O marketing diz compile seu PHP e seja feliz. A doc diz traga só o pedaço que compila. Para CLI, jogo, desktop, WASM e workload pesado de CPU, faz todo sentido. O repositório já mostra exemplos compilando para Android, iOS e Godot. Para levar um Laravel para binário amanhã, não.

Nuno Maduro sobre a chegada de um compilador para PHP e por que generics divide tanto o internals.

## Whim, o PHP que admite que não é PHP [Whim](https://github.com/carthage-software/whim) é outra aposta. É do mesmo Seifeddine Gmati, autor da RFC que não passou, e criador do [Mago](https://github.com/carthage-software/mago), o toolchain em Rust que finalmente fez lint e análise em PHP serem rápidos, com 3.3k estrelas e mais de 1.6M installs. Se o core não aceitou generics, ele fez a linguagem que ele já analisa. Arquivo `.whim`, sintaxe familiar, mas não é PHP. ![Whim e Mago - repositórios da Carthage Software no GitHub](https://opengraph.githubassets.com/1/carthage-software/whim) Whim tem generics reificados com pattern matching em runtime, aquele exemplo de `match` com `Box` diferente de `Box`, tem classes e enums, tasks cooperativas e stdlib própria para HTTP e Postgres. É interpretada, em Rust, com [playground no ar](https://play.whim.sh). Tem vinte e poucas estrelas, é experimental. E é aí que ela me interessa mais, mesmo eu preferindo apagado. Eu concordo com o PHP Annotated, para mim apagado seria mais limpo e mais rápido, checar em dev e rodar sem peso em prod. Mas tudo bem se não for apagado. Whim escolheu reificado e eu entendo a escolha. Ela não finge que é PHP compilado. Ela diz que é outra linguagem com cara de PHP. É mais fácil confiar em algo que admite o que é. O Nuno também comentou o lançamento recente do Whim como basicamente PHP mas com generics, async e pattern matching sem esperar 2030. Vale ver o tom da comunidade no r/PHP, onde o medo recorrente é repetir Hack, Facebook fez HPHPc, depois HHVM, depois Hack, e o ecossistema rachou.

Nuno Maduro apresentando Whim, a linguagem com cara de PHP feita em Rust.

## O Mojo do PHP Muita gente chama os dois de fragmentação, o velho xkcd de criar a ferramenta que unifica quinhentas ferramentas e terminar com quinhentas e uma. Eu não vejo assim. Fragmentação pressupõe que alguém está tentando substituir o centro. Esses projetos são laboratório. Whim para mim é o [Mojo](https://www.modular.com/mojo) do Python. Provavelmente não vinga como produto que vai rodar seu SaaS, mas pode vingar como pressão. Ideias boas vazam de volta para o centro. O PHP já fez isso antes. Hack nasceu de frustração parecida e o core acabou absorvendo parte das ideias com seu próprio tempo e suas próprias restrições. Até um experimento como [userland-php-generics](https://packagist.org/packages/lisachenko/userland-php-generics) que monomorfiza classe em runtime com FFI mostra que tem gente tentando medir o custo real de reificado que o internals diz ser caro demais. Na era de IA isso importa mais do que parece. Eu gero código com modelo todo dia e modelo funciona melhor quanto mais tipo tem. Código bem tipado é mais previsível para máquina e para humano. Se o PHP demora para dar tipos de verdade, a barreira entre linguagens que a IA derrubou joga contra o PHP. Não porque Python ou Rust sejam sempre melhores, mas porque eles deixam o gerador errar menos. Eu preferia apagado. O internals fez bem em dizer não por coerência, mesmo me frustrando. Entre um compilador que promete que seu PHP vai virar binário nativo e uma linguagem nova que admite que não é PHP, eu fico com a segunda. Não porque ela é mais rápida hoje e nem porque eu ache reificado ruim. Fico porque ela não me vende atalho. Ela mostra como seria se a gente começasse de novo sem carregar quarenta anos de compatibilidade. Se o PHP copiar uma boa ideia dela daqui a dois anos, ela já terá valido a pena, mesmo que ninguém faça deploy de um `.whim` em produção. --- Links para acompanhar: [RFC Bound-Erased](https://wiki.php.net/rfc/bound_erased_generic_types) e [discussão no internals](https://discourse.thephp.foundation/t/php-dev-rfc-discussion-bound-erased-generic-types/5446), [A generic tragedy do Brent](https://tempestphp.com/blog/a-generic-tragedy), [TypePHP no GitHub](https://github.com/swoole/typephp) e [doc de performance](https://swoole.com/aot/en/docs/performance), [Whim no GitHub](https://github.com/carthage-software/whim) e [Mago](https://github.com/carthage-software/mago).