De PHP/Laravel a Go: a conta honesta depois de mais de uma década em PHP

Faz mais de uma década (na verdade, quase duas) que desenho arquiteturas em PHP e um década em Laravel. Hoje mantenho o Rush CMS, meu CMS headless multi-tenant em Laravel + Filament + Octane com RoadRunner, PostgreSQL/JSONB, servindo vários sites em produção em um único painel. Venho testando Go em paralelo, planejando a v2 como uma stack híbrida: Go no core de API, Svelte para o front-end, Python/FastAPI pra camada de IA.

Esse post é sobre o que aprendi no caminho. Não é "Go é melhor que Laravel", se você quer ver essas batalhas religiosas, aqui não vai ser o lugar, essa pauta é preguiça de quem nunca botou sistema sério em produção. Vou falar sobre quando cada ferramenta paga seu preço, e por que uma decisão que parece ideológica é, no fim, contábil.

Vou usar Laravel como PHP, por que, para ser sincero, não lembro a última vez que saí do ecossistema Laravel para usar PHP puro.

Sobre a Lógica de Negócio

A facilidade do Laravel

O Laravel opera sob "convenção sobre configuração" e entrega um ecossistema pronto: Eloquent, filas, autenticação, roteamento. Pra validar ideias ou manter sistemas onde time-to-market é a métrica principal, ele elimina o atrito inicial e entrega produtos de altíssimo nível.

No Rush CMS, o Filament me deu um painel administrativo completo em dias, não em semanas. Eloquent + JSONB no Postgres resolve esquemas dinâmicos por tenant sem DDL nem migration hell. Essa produtividade não é detalhe, é o que viabiliza um produto de nicho ser sustentável como operação solo.

Não existe almoço grátis, e a conta chega na escala. A flexibilidade do PHP e a "mágica" do framework cobram caro na manutenção de longo prazo. Pra garantir segurança corporativa e evitar regressões, é estritamente necessário impor barreiras de qualidade externas:

• Clean Code e SOLID aplicados com rigor;
• Suítes com centenas de testes automatizados e análise estática severa no CI/CD (PHPStan em níveis altos, Spatie Data + Value Objects pra simular a previsibilidade de uma linguagem tipada);
• Adotar Octane cedo, senão você vai ter que adaptar todo o código depois.

Isso custa tempo de engenharia e uma luta constante pela performance.

O pragmatismo do Go

Go foi desenhado pelo Google pra resolver problemas de engenharia em larga escala. Não tem herança tradicional, não tem classes, usa composição via structs e interfaces implícitas. Em Go não tem mágica. O tratamento de erros é explícito, o que obriga o engenheiro a lidar com a lógica de falha na hora da escrita, não em produção às 3h da manhã. Você troca incidentes críticos por boilerplate.

A ausência de um framework monolítico dominante força um System Design mais agnóstico. A lógica tende a ficar isolada da camada de entrega (HTTP, gRPC), facilitando DDD. O código resultante é verboso (para não dizer... feio que dói!), mas extremamente legívell qualquer engenheiro novo consegue entender um handler Go em minutos. A falta de elegância é paga pela performance bruta.

Em um dos testes que rodei, um fluxo que no Laravel exigiria job + worker + Redis + Horizon cabia num binário Go resolvendo tudo no mesmo processo. O código ficou chato, a operação ficou trivial.

System Design

Concorrência vs. processamento síncrono: Go vence com folga, o que é óbvio e o mínimo a se esperar, dada a natureza de cada ecossistema.

O modelo tradicional do PHP levanta um novo estado a cada requisição. Pra lidar com processamento assíncrono, a arquitetura obrigatoriamente envolve componentes externos: workers, Redis pra controle de estado, brokers tipo RabbitMQ pra filas, Octane sob alta demanda. Isso multiplica a complexidade de deploy e monitoramento com vários containers, vários processos, várias superfícies de falha.

Em Go, concorrência é nativa via Goroutines. Você dispara milhares de execuções simultâneas com custo de memória irrisório. Pra tarefas de background de complexidade moderada, o System Design em Go elimina a necessidade de workers externos. Um único binário gerencia requisições HTTP e processamento concorrente no mesmo processo.

Isso não significa "sem gargalos" - significa que os gargalos mudam de lugar. Você para de brigar com orquestração de workers e passa a brigar com design de goroutines, channels e backpressure. É outro problema, mas um problema que cabe dentro de um processo só.

No provisionamento de servidores, o Go destrói na eficiência. Uma stack Laravel exige PHP-FPM + Nginx (e Redis + worker + supervisor se o sistema for sério), cobrando seu preço em RAM. Um binário Go é estático, ocupa dezenas de MB no disco, consome uma fração da memória e inicializa em milissegundos. Um VPS modesto que hoje roda um Laravel apertado roda confortavelmente um serviço Go equivalente — e ainda sobra margem.

Sobre Laravel Octane

O Octane altera a premissa fundamental do PHP. É o que sustenta hoje o backend do Rush CMS e de todos os sites dos meus clientes. Em vez de inicializar o framework, carregar dependências e destruir a memória a cada request, ele faz o bootstrap uma vez e mantém a aplicação viva em RAM. A latência de inicialização vai pra zero. I/O, resoluções do Service Container e carregamento de configurações deixam de ser gargalo. O resultado é um aumento massivo de RPS no mesmo hardware, encurtando drasticamente o gap pra binários compilados.

O preço? Gestão de estado.

Rodar PHP em memória exige uma maturidade de engenharia severa. O modelo shared-nothing perdoava código mal escrito — tudo morria no final da request. Com Octane, memory leaks e poluição de estado em singletons viram riscos reais em produção. O PHP não foi desenhado pra rodar indefinidamente, e o Garbage Collector da linguagem nunca foi arquitetado pra processos que ficam vivos por semanas. Pra Octane ser viável, a base de código exige disciplina implacável.

"Se o Octane faz o que o Go faz, por que diabos você tá testando Go?"

A pergunta é óbvia, ela aparece sempre que alguém sênior em PHP flerta com linguagens compiladas. A resposta é simples: o Octane é adaptação brilhante, o Go é nativo. O Octane faz o PHP operar parecido com Go, mas a linguagem não nasceu pra isso. Você passa a lutar contra o ecossistema pra garantir que um singleton mal injetado não vaze memória entre requests e derrube o servidor. O Go não tem esse problema — ele é esse problema, resolvido.

Saber extrair o máximo do PHP paga as contas e entrega produtos fantásticos. É o que faço todo dia. Mas ter maturidade arquitetural pra saber a hora de isolar gargalos usando uma linguagem compilada é o que separa quem entrega features de quem desenha sistemas preparados pra escala real. Expandir a mente pra novas abordagens prepara o engenheiro pra resolver problemas que o ecossistema base simplesmente não permite.

Custos, Equipe e Retorno

Aqui mora a decisão que ninguém quer tomar com honestidade. Vou tomar.

• Mão de obra: Laravel é a porta de entrada mais pavimentada que existe no desenvolvimento web. No Brasil, você acha dev Laravel júnior e pleno em qualquer esquina, com tabela salarial previsível e um ecossistema de boot camps alimentando o mercado. Go é outra realidade: menos devs, tabela salarial mais alta, processo de contratação mais demorado. Em um time pequeno ou em uma operação solo, isso é decisivo. A produtividade por dev Go experiente costuma ser mais alta em domínios de concorrência e sistemas, mas você paga por essa diferença em salário e em escassez de substituto.
• Infraestrutura: Aqui o Go brilha. Um serviço Go ocupa uma fração dos recursos de um Laravel equivalente (mesmo com Octane). Traduz isso pro seu provedor: menos vCPUs, menos RAM, menos containers, menos orquestração. Em escala, a conta da AWS/Hetzner/DigitalOcean cai em ordem de magnitude pra workloads de alta concorrência. Se o produto é I/O-bound ou tem picos sérios, o payback de infra vem rápido.
• Velocidade de negócio: Aqui o Laravel brilha. Do zero ao MVP funcional com auth, painel admin, CRUD, filas e billing, Laravel + Filament chegam em semanas. Em Go você monta isso na unha — e cada peça que você monta é uma peça que tem que manter. Pra startup early-stage, produto interno de empresa, freelance ou validação de ideia, essa diferença de velocidade é o que decide se o projeto nasce ou morre.
• Manutenção de longo prazo: Laravel bem escrito dura anos. Laravel mal escrito também dura anos — só que cada mudança dói mais que a anterior. Go bem escrito dura décadas praticamente sem alteração, porque a linguagem mal evolui (e isso é uma feature, não bug). Go mal escrito ainda é mais previsível que PHP mal escrito, porque o compilador barra muita bobagem na porta.

A conta final depende de qual dimensão é restrição no seu contexto. No Rush CMS v2, a restrição virou infra e previsibilidade de runtime.

Concluindo o inconclusivo

Se você chegou até aqui, já sabe que não existe "escolha definitiva", existe ferramenta certa pro momento do negócio.

Com PHP você valida um produto infinitamente mais rápido. O Laravel otimiza a produtividade humana trocando hardware por horas de dev poupadas, e em um mundo onde dev é caro e hardware é barato, essa é uma troca vencedora no começo da curva. Mas se a operação não tem prazos apertadíssimos e precisa, desde o dia um, lidar com I/O pesado, processamento massivo ou alta concorrência, Go pode ser a decisão mais rentável.

O Go força disciplina através do design e te recompensa com estabilidade absoluta. O Laravel entrega velocidade de negócio extrema, mas exige em troca rigor de qualidade, ferramentas de terceiros e controle de time.

Saber qual dos dois usar, e quando, é o que separa o engenheiro do desenvolvedor.