Bun reescreve 535 mil linhas de Zig para Rust em quatro meses e elimina vazamentos de memória

Jarred Sumner, criador do Bun, anunciou que o runtime de JavaScript/TypeScript — que também é bundler e gerenciador de pacotes — foi reescrito de Zig para Rust. O objetivo: acabar com vulnerabilidades recorrentes de segurança de memória usando o borrow checker do Rust. A reescrita assistida por IA saiu em 4 meses, em vez do ano estimado.

Por que fazer isso

Sumner explica a motivação por trás do que começou como um teste:

Uma grande porcentagem dos bugs [...] são use-after-free, double-free e "esqueci de liberar" em um caminho de erro. Em Rust seguro, isso vira erro de compilador e limpeza automática no estilo RAII com Drop. Erros de compilador são um ciclo de feedback melhor do que um guia de estilo.

Historicamente, reescritas são uma ideia terrível. [...] O Bun tem 535.496 linhas de Zig. Uma reescrita em outra linguagem levaria um time pequeno de engenheiros um ano inteiro. Seria congelar correções de bugs, correções de segurança e desenvolvimento de recursos durante esse tempo.

Por sorte, a suíte de testes do próprio Bun é escrita em TypeScript, ou seja, não depende da linguagem de programação do runtime.

E se, em vez disso, eu passasse uma semana testando se o novo modelo da Anthropic consegue reescrever o Bun em Rust?

No começo, não achei que fosse funcionar. Alguns dias depois, uma porcentagem alta da suíte de testes começou a passar e vi o quanto o novo código Rust batia com a base original em Zig. Minha opinião foi de "vale a pena tentar" para "vou fazer o merge disso".

Como foi feito

Sumner rodou uma portabilidade automatizada de uma vez só, usando na maior parte da reescrita uma versão pré-lançamento do Claude Fable 5, orquestrada em cerca de 50 fluxos de trabalho dinâmicos. O Zig era transpilado para Rust (possivelmente com Rust unsafe, refatorado depois) e validado contra a suíte de testes existente, com mais de um milhão de asserções. Um guia de portabilidade ajudava o Claude a mapear padrões e tipos. Revisões adversariais de código por agentes detectavam problemas antes da versão final. Cada erro melhorava o processo de implementação em si, em vez de consertar manualmente o código gerado.

Dois arquivos foram fatores-chave: o PORTING.md (com o mapeamento de Zig para Rust) e o LIFETIMES.tsv (com os tempos de vida de cada campo de struct da base de código). Um agente implementador era confrontado por dois agentes revisores adversariais, rodando em janelas de contexto isoladas, com acesso apenas aos diffs dos arquivos. Como Sumner enfatiza:

O implementador não revisa. O revisor não implementa.

O esforço foi distribuído em quatro shards de workspace com 16 agentes cada, ou 64 instâncias do Claude em paralelo. No pico, o sistema gerava cerca de 1.300 linhas de código por minuto e chegava a 695 commits por hora.

Antes do merge, isso consumiu 5,9 bilhões de tokens de entrada não cacheados, 690 milhões de tokens de saída e 72 bilhões de leituras de tokens de entrada em cache — cerca de US$ 165 mil a preços de API. Na mão, acho que levaria uns 3 engenheiros com contexto total da base de código cerca de um ano.

Validação e resultados

Depois de a suíte de testes passar com mais de 1 milhão de linhas de código, vieram mais testes e validações, que revelaram novos problemas. A natureza mecânica da portabilidade introduziu 19 regressões semânticas sutis, enraizadas em semelhanças sintáticas entre Zig e Rust. Onze rodadas de revisão de segurança do Claude Code Security corrigiram várias falhas, e o fuzzing guiado por cobertura 24 horas por dia em todos os parsers do Bun resultou em 15 PRs.

Segundo o time do Bun, a implementação em Rust na versão v1.4.0 resolveu 128 bugs antigos da v1.3.14. Vazamentos de memória nativos foram tratados. Testes de bundling em processo com 2.000 operações consecutivas de Bun.build() estabilizaram em 609 MB no Rust, em vez de passar de 6,7 GB. A vazão de HTTP subiu de 2% a 5%. A v1.4.0 foi lançada em agosto de 2026.

Reações

Andrew Kelley, criador do Zig, publicou uma reação dura, intitulada "My Thoughts on the Bun Rust Rewrite":

Há uma dicotomia sendo apresentada aqui, em que você tem que escolher entre um "guia de estilo" ou um recurso de linguagem para evitar bugs. O truque desvia o leitor do principal jeito de eliminar bugs: dedicar recursos de engenharia a isso. [...]

O argumento para enviar todas as milhões de linhas de código não revisado é que a suíte de testes é boa o suficiente para pegar tudo. Então por que você diz que tem tantos bugs chatos no código Zig? O que aconteceu com a suíte de testes ser suficiente para pegar tudo? Ela não é suficiente para pegar bugs no código Zig, mas é suficiente para pegar bugs em 1 milhão de linhas de porcaria não revisada?

Em paralelo, o usuário vitaminCPP defendeu que mergulhar mais de um milhão de linhas de código transpilado por máquina faz do Bun um canário importante do setor: será que bases de código gigantes geradas por LLM continuam mantíveis ao longo do ciclo de vida da engenharia de software?

O Bun foi adquirido pela Anthropic em dezembro de 2025. Quem quiser se aprofundar pode ler o artigo completo, que traz explicações técnicas detalhadas e ilustrações.

Fonte: baseado na análise de Bruno Couriol, publicada pela InfoQ. Acesse a matéria original.