O PHP 8 chegou, e daí?
Tags: php, community, analysis, jit
Published: 2020-12-21 13:55:45

Salve! Uma merecida atualização acaba de sair do forno para a linguagem mais amada e mais odiada da web. Entre as diversas melhorias, para quem desenvolve e para os servidores, é uma aguardada evolução. Mas o que muda de fato?

---

No dia 26 de novembro de 2020 foi liberada a versão 8.0 do PHP. Nesta versão a comunidade trouxe diversas melhorias para quem desenvolve com a linguagem. A [página oficial do lançamento](https://www.php.net/releases/8.0/en.php) descreve as principais mudanças.

Caso queira se inteirar de verdade nas principais novidades, sugiro fortemente o [artigo do Nickolas Silva](https://thephp.website/br/edicao/php-8-features/), que explica melhor cada uma. Caso você seja uma pessoa mais dos vídeos, há uma [playlist do Vinicius Dias](https://www.youtube.com/playlist?list=PL3j2sfzg3FPuQXklYI2LumuG7jgZsj7cK) sobre cada uma das novas funcionalidades. Eles com certeza apresentarão os novos recursos muito melhor do que eu faria.

Acho que você já entendeu que eu não vou falar da perspectiva de desenvolvimento. Deixo isso para as pessoas mais competentes que eu nisso. Quero abordar com você o que muda na prática para administradores de infraestrutura, líderes de times de desenvolvimento e tomadores de decisão em produtos de tecnologia. Caso você seja quem desenvolve, sugiro que siga a leitura e tenha uma perspectiva mais abrangente sobre esse lançamento.

Se você lidera um time que usa PHP mais cedo ou mais tarde vai receber o pedido de atualização - se já não o tiver recebido. Obviamente os desenvolvedores querem utilizar quão antes a nova versão. Mas, pelas vantagens ou meramente pela novidade? Isso acontece com quase todas as linguagens, acredite. Mas, assim como não colocamos nosso sistema em produção sem a avaliação adequada, devemos fazer o mesmo com a atualização de tecnologia.

Uma mudança de tecnologia, como é a do PHP 8, traz também um “checklist” para atualizarmos nossas aplicações. O PHP tem um [guia de migração](https://www.php.net/manual/pt_BR/migration80.php) muito completo (ainda não traduzido). As grandes linguagens têm uma preocupação muito grande com retro compatibilidade, então não deveria ser um problema migrar, certo? Se o código do seu produto é bem escrito, sim. Na [página sobre incompatibilidade com versões anteriores](https://www.php.net/manual/pt_BR/migration80.incompatible.php) há uma mudança drástica na comparação de tipos, uma correção, que pode facilmente quebrar uma aplicação “não tão bem desenvolvida”. E é só o primeiro item da lista. Ainda devem ser verificadas as [notas de obsolescência](https://www.php.net/manual/pt_BR/migration80.deprecated.php) e [outras mudanças](https://www.php.net/manual/pt_BR/migration80.other-changes.php).

Claro, estes são cuidados básicos que qualquer pessoa tomaria certo? (sarcasmo) Falei sobre um aspecto trabalhoso de uma migração. Mas uma atualização de tecnologia sempre traz muitas vantagens também. Performance, estabilidade, melhorias para as pessoas que desenvolvem, APIs que abrem novas possibilidades. Correções de problemas. Melhorias de segurança. Estes últimos normalmente acabam ofuscados pelas outras novidades e deveriam ser os principais motivos para uma atualização.

### Certo, e o PHP?

Creio que você ainda tenha certa ansiedade para que eu fale sobre o que de fato o PHP 8 traz de novidade. Para isso preciso contextualizar a atual situação do PHP. Segundo as pessoas que não leem muito além do título dos artigos, o PHP está morrendo. Estamos em 2020 e ainda tem gente que acha que o PHP é uma linguagem pobre e um queijo suíço quanto a segurança, como talvez já tenha sido há… 20 anos (provavelmente todas as linguagens naquela época eram). Já adiantando o papo: o PHP é bem diferente daquela época, assim como você também é (espero).

Segundo o [W3Techs](https://w3techs.com/technologies/details/pl-php), o PHP é usado em 79% dos sites monitorados por eles - seguido do ASP.NET com 9%. “PHP não escala” - pergunte ao Facebook, Wikipedia ou Washington Post. “Não é orientado a objetos”: nunca foi a proposta principal do PHP que, apesar disso, suporta muito bem o paradigma. O PHP é uma solução robusta para aplicações web há muito tempo. Robusta e segura, com correções de segurança tão logo qualquer vulnerabilidade apareça. Com agenda confiável de atualizações.

Embora a versão 7 do PHP tenha tido um salto impressionante de performance no lançamento, comparado com a versão 5, houve também muitas melhorias na linguagem. Principalmente para projetos que tiram proveito de boas práticas de design. A declaração de tipos foi um grande avanço na linguagem que permitiu que desenvolvedores tirassem proveito de contratos mais precisos - e foi ficando cada vez melhor a cada nova versão anual (7.0, 7.1 … 7.4).

Acho que o lançamento do PHP 7 foi ofuscado por algumas coisas. A polêmica da versão 6 e a não implementação de uma funcionalidade que veio somente agora podem ter lá sua culpa. Mas acredito que o lançamento aconteceu em meio a uma explosão de novas linguagens no mercado. Go, Clojure, Elixir, que são ótimas aliás, ganharam a atenção rapidamente e as pessoas mais ligadas as novidades, e novas oportunidades de trabalho surgindo foram conquistadas rapidamente.

O problema aqui é que os projetos usando PHP não se prepararam ou demoraram para atualizar e podem ter perdido para o apelo da novidade. Já ouvi muitos relatos semelhantes nos últimos anos. Há inúmeros sites e sistemas rodando em PHP 5, que já não recebe atualizações há quase 2 anos. Precisamos atualizar tudo no dia do lançamento? Não. Mas podemos nos preparar.

### E daí? E o PHP 8?

O PHP 8 não traz melhorias significativas de performance com somente a instalação. Esta versão foi focada em entregar melhorias para o desenvolvimento e possibilidades antes inexistentes. Essa versão, somada ao mercado de desenvolvimento ter esfriado quanto as novidades (e hypes) e ao momento mundial podem dar ao PHP uma nova cara para quem não conhece a linguagem ou mesmo tinha o errôneo conceito que citei anteriormente.

As novidades de código, como annotations attributes, promoção de propriedades, argumentos nomeados, tipos union e mixed, operador nullsafe, junto a tudo o que mudou no PHP desde a versão 5 (2004), dão a linguagem a robustez para não dever em possibilidades de implementação a nenhuma outra. O time de desenvolvimento tem, mais do que nunca, o poder de criar soluções com contratos fortes, com gerenciamento de erros e exceções mais eficiente e facilidades de sintaxe para acelerar o desenvolvimento.

Os times que puderem contar com as versões mais recentes do PHP terão, sem uso qualquer framework, um ferramental impressionante. Usando frameworks isso exponencia. Na prática estas novidades resultam em menos código para a mesma solução. Com menos código, a possibilidade de problemas reduz drasticamente. Com menos problemas, reduzimos o custo de manutenção e o impacto desses, agora não tão possíveis, problemas para os nossos clientes.

Outro ganho indireto é na produtividade. Sabendo usar o novo ferramental os nossos times podem tirar proveito de implementações mais simples, melhor testáveis e mais estáveis. O código torna-se mais estável e robusto com menos esforço. O preço dessa melhora é o desenvolvimento e adequação do time. Mas isso você já está fazendo, não?

A outra grande novidade do PHP 8 é o JIT (Just-In-Time) - ou melhor: os motores de compilação JIT. Resumidamente, agora o PHP é capaz de otimizar o processo de execução, rodando o programa mais próximo a CPU, sem intermediá-lo na ZendVM (como acontecia desde o PHP 4, 2000). O Nickolas entra nos [detalhes dessa implementação em outro (ótimo) artigo](https://thephp.website/br/edicao/php-8-jit/) - recomendo a leitura. Junto a outras medidas adotadas ao longo das grandes versões do PHP, como opcache e preloading, o JIT promete grandes ganhos para o PHP, mas não são exatamente de performance.

![Diagrama do plano de execução do PHP 8](https://dev-to-uploads.s3.amazonaws.com/i/tar2h8w5vwbop6r836hp.png)

O diagrama acima, (in)devidamente copiado e traduzido do artigo do Nickolas, mostra como é a estratégia de execução do PHP. Com o JIT habilitado, a execução basicamente segue o fluxo Sim e Sim após a primeira execução. Como neste caso estamos “ignorando” a ZendVM na execução, o processamento é bem mais ágil, no nível da CPU. Com isso temos ganhos significativos em processamento do PHP. Mas não se aplica a operações externas ao PHP, como manipulação de arquivos, conexões com bancos de dados, consumo de API etc. Aplicações complexas, que demandam de alto nível de processamento, serão as mais beneficiadas com a novidade.

Mas vou além. Conforme mencionado na própria RFC do JIT, há muito mais. A implementação do JIT abre mais possibilidades para o uso do PHP além da web. Normalmente em cenários de uso intensivo de processamento a linguagem é pouco ou não considerada. Um caso de uso poderia ser o de aprendizado de máquina - onde ainda há raras tentativas. Outra possibilidade fica em processamento de som (desde que não haja interação com o armazenamento). Há um mundo de novas possibilidades!

Outro ponto crucial da introdução do JIT é a possibilidade de desenvolver funções nativas do PHP em código PHP. Explico: será possível que mais pessoas da comunidade, que hoje têm a barreira da linguagem C, possam contribuir com o código fonte da linguagem. Além disso as implementações com essa abordagem serão mais seguras, visto que não haveria todo o código de controle necessário no desenvolvimento em C. Nas palavras dos autores, isso abre portas para inovação mais ágil.

---

O que podemos esperar agora? No curto prazo, nada. As bibliotecas já estão atualizando seu código fonte para tirar proveito das novidades. A grande parte das aplicações existentes rodam sobre frameworks que ainda serão atualizados. Ainda haverá um trabalho de otimização e correção das aplicações para que funcionem bem na nova versão. A partir deste ponto veremos as atualizações tornarem-se mais robustas e novos tipos de soluções.

Os profissionais dentro e fora da bolha dos que palestram e escrevem terão mais possibilidades no dia a dia e têm hoje no PHP uma suíte completa para produzir as soluções que precisarem. Necessito de mais informação e tempo para afirmar com mais precisão, mas acredito que os custos com servidores podem cair significativamente com o JIT, o que pode resultar em melhorias para os times.

Bem-vindo PHP 8!

---

(originalmente publicado em https://casimiro.page/post/o-php-8-chegou.e-dai/ )