Buz – fork do Bun com suporte ao Zig mais recente e builds incrementais em menos de 1 segundo

• Buz é um fork em estágio inicial que parte do commit imediatamente anterior à reescrita do Bun em Rust e está sendo desenvolvido com o objetivo de ser um substituto compatível baseado no Zig mais recente
• Todo o grafo de build, incluindo o código vendorizado do JavaScriptCore, foi migrado para build.zig, e pequenos patches foram aplicados ao Zig para viabilizar builds incrementais em menos de 1 segundo
• Foram trazidos testes de novos recursos e correções de bugs da versão Rust do Bun, mas muitos ainda falham, então é preciso continuar acompanhando os recursos upstream e as mudanças no JavaScriptCore
• Mais de 11.000 linhas de código não utilizado foram removidas, e vários bugs também foram corrigidos no processo de modernizar parte da implementação com foco maior na biblioteca padrão do Zig
• Ainda não está pronto para uso em produção, e o objetivo de longo prazo é reduzir a dívida técnica com ajuda de LLMs e supervisão humana para criar uma base de código fácil de manter mesmo sem LLMs

---

Objetivos do projeto e estado de desenvolvimento

• Buz é um fork em desenvolvimento baseado no último commit antes de o Bun ser reescrito em Rust
• O foco é ser um substituto compatível com o Bun e, ao mesmo tempo, criar uma base de código mais organizada do que a original
• O desenvolvimento ainda está em fase muito inicial, então não está pronto para uso em produção
• O Buz foi publicado para evitar duplicação de trabalho, já que um projeto semelhante de Bun em Zig já havia sido divulgado no Ziggit
  • No momento da publicação, esse projeto ainda não havia sido analisado

Port para o Zig mais recente e builds incrementais

• O Bun foi portado para o Zig upstream atual, com pequenos patches aplicados ao Zig para permitir rebuilds incrementais
• Todo o grafo de build, incluindo o código vendorizado do JavaScriptCore, foi integrado ao build.zig
• Com essa configuração, o tempo de build incremental caiu para menos de 1 segundo, acelerando o ciclo de desenvolvimento
• O projeto inclui um submódulo do Zig master com o patch de build incremental aplicado
• Também é possível compilar normalmente com o commit upstream do Zig 2b1c663

Testes de compatibilidade e acompanhamento do upstream

• Foram trazidos os testes adicionados à versão Rust do Bun, incluindo muitos que verificam novos recursos e correções de bugs
• Ainda há muitos testes que não passam, então é preciso continuar acompanhando o upstream do Bun
• O trabalho de organizar o código e reduzir a dívida técnica segue em paralelo, mantendo a compatibilidade de recursos
• As mudanças no JavaScriptCore também precisam ser acompanhadas continuamente

Limpeza e modernização da base de código

• Foram removidas mais de 11.000 linhas de código completamente não utilizado no Bun
• Parte do código foi reescrita e modernizada, aumentando o uso da biblioteca padrão do Zig
• Vários bugs também foram corrigidos durante esse processo de limpeza e modernização
• A base de código atual do Bun tem cerca de 600 mil linhas, e a avaliação é de que será preciso reescrever um número considerável de subsistemas para chegar a um estado mais organizado

Uso de LLMs e política de contribuição

• Há o plano de fazer uso extensivo de LLMs para organizar o código legado complexo, junto com supervisão humana e práticas de desenvolvimento melhores
• Até que a base de código seja considerada suficientemente organizada, contribuições escritas diretamente por pessoas não serão aceitas
• A prioridade é reduzir a dívida técnica e escrever código Zig idiomático, com a meta de chegar em semanas ou meses a uma base de código que possa ser lançada como substituto compatível do Rust Bun 1.4.0
• Desenvolvedores que possam usar Sol ou Fable são convidados a ajudar
• No longo prazo, a meta é criar uma base de código fácil de manter sem ajuda de LLMs e, durante o processo, também elevar o domínio de Zig

[GN⁺]

Comentários do Hacker News

• O fato mais interessante deste fork é que ele provou que o Bun já poderia compilar rápido há muito tempo
  A compilação incremental do Zig ainda não suporta aarch64 e o patch binário só é possível no linker do Linux, mas o suporte às principais plataformas parece ser apenas uma questão de tempo
  • Considerando toda a comoção em torno de terem feito um fork do compilador Zig para acelerar os builds, surpreende que este não seja o comentário mais votado
    O fato de que uma equipe de uma pessoa conseguiu builds de 1 segundo mostra que os builds lentos eram resultado de práticas de desenvolvimento descuidadas, e que gastar tempo no fork foi uma alocação de recursos completamente equivocada
• Arrumar com LLM o código que a própria LLM estragou: parece que chegamos ao auge da tecnologia em 2026
  • Até agora, humanos também vinham arrumando código que humanos estragaram, então não há contradição lógica
  • O resultado da LLM fica tão bom quanto a capacidade do usuário que a instrui
  • Sou cético em relação à IA, mas disposto a usar; se a LLM realmente conseguir arrumar sozinha o próprio resultado, isso pode mudar o jogo
  • Pensei a mesma coisa, mas logo depois ele diz que os humanos vão manter o controle, reduzir a dívida técnica e escrever código Zig permissivo para criar, em semanas ou meses, uma base de código capaz de substituir o Rust Bun 1.4.0
    No fim, parece querer dizer que vão dar mais instruções, ou instruções melhores. A estrutura do código também parece um pouco questão de gosto; ontem tive uma conversa absurda com um colega que insistia que eram necessários quatro processos de backend para lidar com uma única requisição HTTP
  • Sempre foi nessa direção. Como outputs quebrados de LLM, ilegíveis ou incompreensíveis para humanos, estão virando código, todo código acabará tendo de ser feito para ser lido e escrito por máquinas
    A era de intervenção humana sempre foi apenas uma fase temporária
• Surpreende que tenham removido 11 mil linhas de código totalmente morto do Bun, modernizado o projeto para usar mais a biblioteca padrão e ainda corrigido vários bugs
  Fico curioso se isso é comum em projetos grandes e eu só não sabia
  • O total é de 600 mil linhas, então o código morto representa cerca de 1,8%. Em bases grandes, é mais comum porque para decidir se um código realmente não é usado é preciso olhar um escopo amplo, e mudanças distantes ao longo do tempo também podem transformar código em morto
    Não está claro se era código óbvio como if (false) { dead_code(); } ou código que poderia ser chamado por despacho dinâmico, mas que logicamente nunca seria alcançado. No primeiro caso, 1,8% é alto; no segundo, talvez seja baixo. Também há muitos projetos com código atrás de feature flags antigas que na prática nunca mais roda
    Uma pequena quantidade de código morto, como utilitários simples ou código gerado, pode não ser um problema, mas removê-lo às vezes leva a uma cascata de exclusões e simplificações
  • Na empresa anterior, reduzi um componente de 10 mil linhas para 2 mil linhas e corrigi todos os bugs principais
    Tecnicamente não era código morto, mas quando você limpa uma pequena abstração errada, surgem várias oportunidades de limpeza em sequência, e no fim sobra um software que faz apenas o que deveria fazer. Bases de código incham com o tempo, então me surpreende mais que, no tamanho do Bun, tenham encontrado só 11.000 linhas
  • O compilador Zig faz compilação preguiçosa, então não detecta funções mortas que não são chamadas por nenhuma função compilada
  • Considerando o estilo de desenvolvimento do Bun, é menos do que eu esperava; deve haver muito mais na base de código
  • O mais surpreendente é alguém se surpreender com essa quantidade de código morto em uma base grande. Isso dá, no máximo, uns 10 PRs de tamanho normal
• Fico curioso sobre há quanto tempo você programa para achar 11 mil linhas de código morto algo tão incomum
  • Tenho mais de 10 anos de experiência. Quis dizer código morto óbvio, não chamado de lugar nenhum, e fiquei curioso se existem muitos outros projetos com tanto assim
• Em todo projeto de coding centrado em agentes, apareceu uma oscilação tique-taque entre desenvolvimento de funcionalidades e manutenção do código
  Na fase do tique, adiciona-se funcionalidade rapidamente para criar uma versão correta, porém extremamente bagunçada; na fase do taque, digere-se e organiza-se o resultado para melhorar desempenho, manutenção e resistência a mudanças
  Costumo passar um dia fazendo vibe coding para criar um app funcional e depois uma semana transformando-o em um projeto no qual dá para continuar adicionando recursos sem ele desabar como um castelo de cartas. Antes da IA já era parecido, mas desenvolvedores profissionais tinham um modelo mental mais forte do sistema e trabalhavam mais devagar, então a transição não era tão abrupta
  • No fim, é preciso olhar o código diretamente e verificar se a lógica não está duplicada por toda parte e se ele é realmente manutenível
    Modelos de coding têm forte tendência a quebrar encapsulamento ou copiar código que não deveria ser duplicado
• Eu chamaria isso de programação de performance para se exibir. Gosto de performance e os tempos de build também deveriam se aproximar de zero, mas já entramos na zona de retornos decrescentes, e o gargalo atual provavelmente não é o build
  • Os desenvolvedores do Bun provavelmente discordariam, já que sofreram pessoalmente longas esperas sem poder usar compilação incremental: https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
    Em projetos grandes, não dá para esperar vários minutos toda vez que se roda teste ou se verifica erro semântico, então tempo de build é claramente um gargalo
  • Para projetos assim, builds rápidos são essenciais e parecem um passo importante para facilitar a manutenção
• Se o Bun for mantido por alguém que se importa com qualidade de código, será bem-vindo, mas é uma tarefa hercúlea
  • Mais do que hercúlea, parece uma tarefa sisífica sem fim
• Pelo contrário, eu também gostaria de ver um fork de Zig que só aceitasse contribuições de IA
  Não por apoiar fortemente IA, mas como arte conceitual ou experimento seria divertido ver como os dois projetos evoluem de formas diferentes
• O também muito relevante Cruller usa a base de código do Bun anterior à reescrita, mas foca apenas na parte de runtime para produção
  Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
  Discussão no HN: https://news.ycombinator.com/item?id=49017344
• Não entendo por que o Bun gera tanto assunto. Não daria para simplesmente ficar com Node + npm + Vitest + Vite?
  • Existe o projeto Nub, que tenta levar as vantagens do Bun para o Node, e ele também pode mostrar bem por que as pessoas preferem o Bun e onde estão as lacunas das ferramentas existentes
    https://nubjs.com
  • É justamente essa lista que explica o motivo de tanto assunto. Em vez de combinar um monte de ferramentas, você pode usar um runtime único que faz tudo de que precisa
    Não há problema em combinar ferramentas especializadas, mas é muito conveniente quando tudo funciona por padrão. O bundler do Bun também tem uma API de runtime, então o mesmo processo que serve assets pode coordenar com um bundler externo ou fazer bundling direto da memória, sem escrever arquivos estáticos no disco
  • O simples fato de você ter de listar quatro ferramentas já mostra como a situação anterior era ruim
  • Agora já nem está claro por que ainda seria preciso continuar usando npm