Bun reescreve 535 mil linhas de Zig para Rust em quatro meses com IA
Criador do runtime JavaScript usou agentes de IA para portar toda a base de código, eliminou vazamentos de memória crônicos e reabriu o debate sobre confiar em milhões de linhas geradas por máquina em produção.
O Bun, runtime JavaScript↳JavaScript116 conteúdosJavaScript em 2020: O que esperarDev (Back & Front) · jan 2020Campos públicos e privados em classes JavaScript – O que vem por aí no ESNextDev (Back & Front) · abr 201929 anos de JavaScript!Dev (Back & Front) · jan 2025Ver tudo em Dev (Back & Front) →/TypeScript que também funciona como bundler e gerenciador de pacotes, trocou sua linguagem de implementação de Zig para Rust. Jarred Sumner, criador do projeto, anunciou que a reescrita completa de 535.496 linhas de código foi concluída em quatro meses, um trabalho que ele mesmo estimava levar um ano com uma equipe humana dedicada. O resultado foi lançado no Bun v1.4.0, em agosto de 2026, segundo a InfoQ.
A motivação não é estética. Segundo Sumner, boa parte dos bugs históricos do Bun eram use-after-free, double-free e "esqueci de liberar memória" em caminhos de erro, exatamente a classe de falha que o borrow checker do Rust transforma em erro de compilação em vez de bug em produção. Na visão dele, "erros de compilador são um loop de feedback melhor que um guia de estilo".
Como a reescrita foi feita
Em vez de portar o código manualmente, Sumner testou se uma versão pré-lançamento de um modelo da Anthropic (a InfoQ cita como "Claude Fable 5") conseguiria reescrever o Bun inteiro em Rust. O experimento só foi viável porque a suíte de testes do Bun é escrita em TypeScript e não depende da linguagem do runtime: mais de um milhão de assertions serviram de critério objetivo para validar cada trecho transpilado.
O processo foi orquestrado em cerca de 50 workflows dinâmicos, com papéis separados entre agentes: um implementador traduzia o Zig para Rust apoiado em dois documentos vivos, o PORTING.md (mapeamento de padrões Zig para Rust) e um LIFETIMES.tsv (o tempo de vida de cada campo de struct do código-base). Dois agentes revisores adversariais, rodando em janelas de contexto isoladas e com acesso só ao diff, tinham a única tarefa de achar bugs e divergências de comportamento. Um agente corretor tratava os problemas apontados. Sumner resume a divisão de forma direta: "o implementador não revisa, o revisor não implementa".
A escala do processo é o dado que mais chama atenção: o trabalho foi distribuído em quatro shards de workspace, cada um rodando 16 agentes, totalizando 64 instâncias do Claude em paralelo. No pico, o sistema gerava cerca de 1.300 linhas de código por minuto e chegou a registrar 695 commits por hora. Chegar à suíte de testes passando por completo custou US$ 165 mil em tokens de API, o equivalente a 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 cacheados. Para efeito de comparação, Sumner estima que o mesmo trabalho, feito manualmente, tomaria de três engenheiros com contexto total do código-base cerca de um ano.
O que sobrou de bug, e o que apareceu de novo
A reescrita mecânica não saiu de graça. A InfoQ relata 19 regressões semânticas sutis causadas por similaridades sintáticas entre Zig e Rust (código que parece igual nas duas linguagens mas se comporta diferente). Onze rodadas de revisão de segurança com o Claude Code Security corrigiram problemas adicionais, e um regime de fuzzing guiado por cobertura, rodando 24 horas por dia contra todos os parsers do Bun, resultou em 15 pull requests de correção.
No saldo final, o Bun v1.4.0 resolveu 128 bugs que existiam desde a v1.3.14, incluindo os vazamentos de memória que motivaram todo o projeto. O teste citado pela InfoQ é concreto: em um cenário de bundling contínuo, executando 2.000 chamadas seguidas de Bun.build(), a versão em Zig tinha o consumo de memória subindo até passar de 6,7 GB, enquanto a versão em Rust estabilizou em 609 MB. O throughput HTTP também subiu, entre 2% e 5%.
A reação de quem criou o Zig
A reescrita não passou sem contestação, e a crítica mais direta veio de dentro da própria comunidade Zig. Andrew Kelley, criador da linguagem, publicou um texto chamado "My Thoughts on the Bun Rust Rewrite" questionando a narrativa. Segundo ele, existe uma falsa dicotomia entre "escolher uma feature de linguagem ou um guia de estilo" para evitar bugs, quando na prática bugs se eliminam dedicando esforço de engenharia a isso, não trocando de linguagem. Kelley vai direto ao ponto central da controvérsia: se a suíte de testes é suficiente para validar um milhão de linhas de código não revisado por humanos, por que ela não bastava para pegar os bugs que existiam no Zig?
A InfoQ também registra o comentário de um usuário identificado como vitaminCPP, que enquadra o caso de forma mais neutra: o Bun se torna um canário importante para a indústria sobre se bases de código massivas, geradas por LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →, conseguem se manter sustentáveis ao longo do ciclo de vida do software, não só no dia do merge.
O que isso muda para quem escolhe stack aqui
Para quem decide runtime e linguagem em projeto real, o caso do Bun serve como dado concreto, não como recomendação. Primeiro, ele confirma que memory safety continua sendo o argumento mais forte a favor de Rust frente a linguagens sem garbage collector e sem borrow checker: o próprio time do Bun preferiu pagar o custo de uma reescrita inteira a continuar caçando use-after-free em produção. Segundo, ele mostra o tamanho real do custo de uma migração desse porte mesmo com IA: US$ 165 mil em tokens e quatro meses de operação com 64 agentes em paralelo não é algo que cabe no orçamento da maioria dos times, e a comparação de custo com
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
