Bun troca Zig por Rust: 535 mil linhas migradas e o que isso ensina sobre grandes reescritas

Reescrever um projeto grande do zero costuma ser listado como um dos erros clássicos da engenharia de software. Pois o Bun, runtime JavaScript/TypeScript que compete com Node.js e Deno, acaba de fazer exatamente isso — e saiu do outro lado com menos bugs, binário menor e desempenho levemente melhor. A equipe portou toda a base de código de Zig para Rust, e o caso, detalhado pela InfoQ neste fim de semana, virou referência obrigatória para quem discute migrações de linguagem.

Por que sair do Zig

A motivação não foi estética. Segundo Jarred Sumner, criador do Bun, boa parte dos bugs críticos da série 1.3 eram do tipo use-after-free, double-free e memória que nunca era liberada — em módulos como node:zlib, node:http2 e UDPSocket. Zig dá controle manual total sobre memória, o que é ótimo para desempenho, mas deixa esse tipo de erro para ser descoberto em produção, em fuzzing ou em code review. Em Rust, o borrow checker transforma a maior parte dessas falhas em erros de compilação.

Como a migração foi feita

O ponto que mais chamou atenção é o método. A tradução não foi manual: a equipe usou agentes do Claude orquestrados em workflows. Antes de começar, gerou um guia de portabilidade mapeando padrões de Zig para equivalentes em Rust e uma tabela documentando requisitos de lifetime. Depois, 64 instâncias trabalharam em paralelo, divididas em quatro worktrees. Cada mudança passava por revisores adversariais — instâncias separadas, com contexto isolado, instruídas a encontrar bugs no código do implementador.

A régua de qualidade foi a suíte de testes do Bun, escrita em TypeScript e, portanto, independente da linguagem da implementação. Nada entrava sem passar 100% dos testes em todas as plataformas. Os números divulgados impressionam: mais de 535 mil linhas de Zig, 1.448 arquivos convertidos, milhares de commits e um custo estimado de cerca de US$ 165 mil em tokens de API — algo que Sumner compara ao trabalho de três engenheiros com contexto completo durante um ano.

O que muda para quem usa o Bun

Na prática, nada quebra: APIs, arquitetura e testes continuam os mesmos, e a v1.4.0 é a primeira versão com o núcleo em Rust. Os ganhos relatados incluem 128 bugs corrigidos em relação à v1.3.14, binário cerca de 20% menor no Linux e no Windows (de 88 MB para 70 MB), throughput HTTP e builds de 2% a 5% mais rápidos e o fim dos vazamentos em chamadas repetidas de Bun.build() dentro do mesmo processo.

Também houve tropeços, e a equipe foi transparente sobre eles: 19 regressões semânticas surgiram depois do merge, todas corrigidas. Um exemplo didático: em Rust, debug_assert! desaparece em builds de release — levando junto qualquer efeito colateral da expressão —, enquanto o assert do Zig sempre executa. É o tipo de diferença sutil que nenhum tradutor, humano ou IA, pega sem testes bons.

Nem todo mundo está convencido

A recepção não foi unânime. Andrew Kelley, criador do Zig, publicou uma resposta crítica questionando se o argumento de que a suíte de testes era suficiente para validar a migração foi aplicado de forma consistente. Vale lembrar também que o código foi portado de forma mecânica, não reescrito em Rust idiomático — uma escolha deliberada para manter a continuidade do time, mas que significa trechos com unsafe e dívida de refatoração pela frente.

A lição para o resto de nós

Mais do que "IA reescreveu um runtime", o caso do Bun mostra que o ativo mais valioso numa migração é uma suíte de testes abrangente e desacoplada da implementação. Foi ela que permitiu paralelizar o trabalho, detectar regressões e dar confiança para o merge. Se você tem uma migração de linguagem, framework ou versão maior no backlog, a pergunta a fazer antes de escolher ferramentas é simples: meus testes provariam que o comportamento continua o mesmo?