Buz: um fork de Bun em Zig moderno que rebuilda em menos de um segundo

Após a migração do Claude Code para Bun (com núcleo em Rust) na semana passada, um membro da comunidade Zig anuncia o Buz: um fork do Bun reescrito com as versões recentes do Zig, prometendo builds incrementais em menos de um segundo. 224 pontos no topo do Hacker News.

O caso concreto

Bun (o runtime JavaScript concorrente do Node) é escrito majoritariamente em Zig, uma linguagem de sistema que atrai pela promessa de “fazer o que C faz, mas melhor”. Só que, à medida que o Bun cresceu, ele ficou preso em uma versão relativamente antiga do Zig, com tempos de compilação que explodem quando se modifica sequer um arquivo.

Entra então o Buz, um fork anunciado por um membro da comunidade no ziggit.dev (o fórum oficial dos zigueiros) em 24 de julho de 2026. O pitch cabe em uma linha: « drop-in replacement for Bun using modern Zig, with sub-1s incremental builds ». No Hacker News, a notícia rapidamente atingiu 224 pontos e 161 comentários — para um projeto nascente, é um sinal.

Isso chega em um momento crucial para o ecossistema Bun: na semana passada, Simon Willison documentou o fato de que o Claude Code agora usa o Bun (com um núcleo em Rust) — sinal de que o Bun está se estabelecendo na ferramentaria de IA. Cada fricção na velocidade de contribuição vira, portanto, um problema além do projeto em si.

O que precisa ser entendido

O nome do projeto, Buz (“Bun” + “Zig”), não é apenas um trocadilho. Ele documenta a aposta técnica:

• Acompanhar as versões recentes do Zig (a linguagem ainda está em pré-1.0, as breaking changes são frequentes, mas as otimizações do compilador avançam rápido).
• Explorar o compilador auto-hospedado do Zig, que traz builds incrementais de verdade.
• Manter compatibilidade de API com o Bun para não fragmentar o ecossistema (como faz o Deno vs Node).

O ponto-chave são esses builds incrementais sub-segundo. Quando se mexe em um runtime tão grande, cada ciclo “mudo uma linha → testo” conta. Passar de dezenas de segundos para menos de um segundo muda completamente a ergonomia de contribuição — é o tipo de detalhe que decide se um projeto atrai devs externos ou fica preso à equipe fundadora.

O debate real

Os comentários no HN se dividem em dois grupos:

1. Os entusiastas — um fork mantido pela comunidade pode destravar coisas que Jarred Sumner (fundador do Bun) nunca teve tempo de atacar. Exemplo notável: os forks OpenSSL/LibreSSL ou o io.js, que forçou a mão no Node.js.
2. Os céticos — o risco de divergência é real. Um “drop-in replacement” que erra 5% das APIs acaba criando mais problemas do que resolve. E manter um fork ativo de um projeto tão grande quanto o Bun exige gente.

Nossa leitura

Provavelmente é mais interessante como prova de conceito do que como concorrente sério do Bun. Se o Buz demonstrar que é possível ter builds sub-segundo em uma base de código desse tamanho, a equipe do Bun terá todo o interesse em incorporar as otimizações upstream — o que beneficiaria a todos. O padrão “fork que empurra o original a evoluir” é uma constante no software livre.

A se observar: a frequência dos commits nas próximas semanas. Um fork que morre depois de 15 dias, isso acontece o tempo todo; um fork que resiste por 3 meses já começa a contar.

Para guardar O Buz ainda não é um substituto crível do Bun, mas aponta um problema real: a estagnação da versão do Zig usada pelo Bun freia a velocidade do projeto. Quer o Buz dê certo ou não, o efeito mecânico será forçar o Bun a migrar mais rápido — o que também se conecta com o novo posicionamento do Bun na ferramentaria de IA (Claude Code).