PR de reescrita do Bun em Rust foi mesclado

• O PR #30412 traz a mudança de reescrever o Bun em Rust e foi mesclado de claude/phase-a-port para main em 14 de maio de 2026
• A escala da mudança aparece como 6.755 commits, 2.188 arquivos e +1,009,257/-4,024 linhas
• Jarred-Sumner afirmou que um post de blog com mais detalhes será publicado em breve
• Foi explicado que essa mudança passa pela suíte de testes existente do Bun em todas as plataformas e corrigiu vários vazamentos de memória e testes instáveis
• O tamanho do binário diminuiu de 3 MB a 8 MB, e os benchmarks foram descritos como neutros ou mais rápidos
• Como motivo mais importante, foi dito que agora será possível detectar e prevenir bugs de memória nos quais a equipe gastou grandes quantidades de tempo de desenvolvimento e depuração ao longo de anos, com ajuda de ferramentas assistidas pelo compilador
• Foi explicado que a base de código continua praticamente a mesma, e que a arquitetura e as estruturas de dados também foram mantidas
• O Bun continua usando poucas bibliotecas de terceiros, e foi especificado que async Rust não é utilizado
• Os usuários podem testar essa mudança com bun upgrade --canary
• Jarred-Sumner pediu que, caso surjam problemas, sejam abertas issues, e afirmou que poderá bloquear a thread se ela ficar acalorada demais
• Ainda restam trabalhos de otimização antes de isso entrar em uma versão não canary
• Ainda restam tarefas de organização, que devem seguir em uma série posterior de PRs

[xguru]

Uau, mergearam um PR de um milhão de linhas. Estão simplesmente migrando de Zig para Rust de uma vez só.
Falaram algo como “nem sei se isso vai ser mergeado~~”, mas em só uma semana trocaram de uma tacada só a linguagem de um código que já estava funcionando direitinho haha
Parece que está acontecendo algo monumental por causa de coding assistido por IA.

[heycalmdown]

Sério? Disseram que era só para testar e que provavelmente nem iam usar.

[freedomzero]

Como o Zig não fez isso, já pularam direto pro Rust na maior ousadia kkk

[GN⁺]

Comentários do Hacker News

• Se na apresentação disseram que o rewrite levou 1 semana, fico curioso para saber quanto tempo levou para preparar esse arquivo de instruções super detalhado mapeando idiomatismos de Zig para idiomatismos de Rust: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573...
  Além disso, olhando as seções Pointers & ownership e Collections, a codebase do Bun já usava tipos internos de smart pointer para ficar preparada para um mapeamento 1:1 com equivalentes em Rust, e o crate Rust bun_collections também já existia
  Esse rewrite parece ter sido preparado há muito tempo e proposto pela equipe do Bun durante as negociações de aquisição pela Anthropic

  • Quando leio textos sobre LLM, nunca sei o que é fato, e o mesmo vale para estes comentários no Hacker News
    Tem dinheiro demais em jogo, então claramente existe incentivo para infiltrar marketing disfarçado na comunidade, e parte disso também é só lógica de torcida
    Agora que a Anthropic é dona do Bun, ela também tem incentivo de sobra para fazer esse trabalho parecer mais fácil do que realmente foi
  • Deixando de lado fatores como a qualidade do código Rust resultante, se a contagem de linhas faz sentido e o quanto a codebase já estava preparada para isso, um documento de 622 linhas parece um custo relativamente pequeno como artefato prévio que pode melhorar a consistência ou a qualidade de uma saída de cerca de 1 milhão de linhas
    A escala da saída é tão grande que parece haver um efeito multiplicador aqui
    Ainda assim, fico curioso sobre quanto conhecimento tácito foi necessário para criar essas regras e o quanto esse arquivo foi refinado iterativamente
    Por exemplo, queria saber quantas dessas regras vieram de casos de falha encontrados durante ciclos repetidos de tradução
  • Você disse using internal smart pointer types that map 1-to-1 to Rust equivalents, mas smart pointers não foram inventados por Rust
    Se você programa em qualquer outra linguagem com ponteiros, já modela os mesmos tipos mentalmente
    E isso de que o crate Rust bun_collections já existia está errado
    Ele só faz parte deste PR da codebase, não existia antes
  • Isso é a mesma coisa da demo do gcc da Anthropic
    Seria muito fácil diminuir a desconfiança e inflar ainda mais o clima de IPO se eles publicassem num repositório separado o trabalho oculto que foi necessário para impulsionar a IA e deixassem todo mundo reproduzir o resultado
    No fim, não é isso que os clientes querem também, 1 milhão de linhas de código utilizáveis em “7 dias”?
    Todo mundo poderia tentar reproduzir isso no próprio workflow, e as métricas de uso da Anthropic também subiriam
    Se o resultado fosse realmente tão incrível, eu esperaria primeiro um post de blog com links e instruções
    Pode ser que eu esteja errado e que esse post esteja sendo escrito neste exato momento
  • Parece que a versão em Zig do Bun tinha 3 tipos de ponteiro que mapeavam bem para tipos de ponteiro já existentes em Rust, e os outros 7 ou 8 precisaram de tipos novos
    Esse é o centro da teoria da conspiração?
    O bun_collections também não parece ser muito mais antigo do que o guia de port

• [phone]: então o Bun agora passou de 1 milhão de linhas de código Rust
  Está chegando perto do tamanho do próprio compilador Rust
  Só que o BunJS é, em grande parte, um wrapper de interpretador JavaScript e uma reimplementação de bibliotecas do NodeJS, ou seja, algo próximo de um wrapper da biblioteca padrão de Rust
  O BunJS parece estar virando um canário para gestão da complexidade de software na era dos LLMs

  • mostly a JavaScript interpreter wrapper não é uma descrição precisa
    O Bun é um transpiler (parser) de JavaScript e CSS com tudo incluído, minifier, bundler, gerenciador de pacotes tipo npm, executor de testes tipo Jest, e ainda tem APIs de runtime como clientes embutidos de Postgres, MySQL e Redis
    Naturalmente isso faz a quantidade de código explodir
  • O Bun não é um interpretador JavaScript, é mais uma reimplementação das bibliotecas do NodeJS e de várias outras bibliotecas
    O Bun usa o JavaScriptCore como engine de JS, então o próprio Bun não faz parsing, interpretação nem JIT de JavaScript, ou pelo menos não deveria fazer
    Edit: li errado. Como você disse “JavaScript interpreter wrapper”, a expressão está correta
  • Não sei se no iOS isso é detectado como número de telefone por causa do + inicial ou por outro fator, mas no celular a mudança de número de linhas fica sublinhada e, se você tocar, pode tentar ligar
    Se for por causa do tamanho do diff, é bem engraçado
  • A codebase do Bun já tinha uma quantidade parecida de linhas de código antes do rewrite
    Não é estranho que o resultado do rewrite tenha saído com LOC semelhante
  • Um wrapper de JavaScriptCore com 1 milhão de linhas é um excelente exemplo do que um agente consegue fazer

• O resultado de $ rg 'unsafe [{]' src/ | wc -l é 10428, e o de $ rg 'unsafe [{]' src/ -l | wc -l é 736
  Por linguagem: Rust 1443 arquivos e 929213 linhas, Zig 1298 arquivos e 711112 linhas, TypeScript 2604 arquivos e 654684 linhas, JavaScript 4370 arquivos e 364928 linhas, C 111 arquivos e 305123 linhas, C++ 586 arquivos e 262475 linhas, C Header 779 arquivos e 100979 linhas

  • É legal que em Rust dê para procurar especificamente por código potencialmente inseguro desse jeito
    Como se procura por código inseguro em Zig?
    Ou tem que simplesmente assumir que ele está em todo lugar?
  • Se metade dos arquivos contém a keyword unsafe, isso não parece um bom rewrite
    Se quase metade do código ainda é unsafe, qual é exatamente o sentido de reescrever em Rust?
  • Espero que o Mythos seja realmente o melhor do mundo, como eles afirmam. Porque agora vai precisar ser mesmo
  • Temos memory safety em casa!
    A memory safety em casa: 10428

• Ainda estamos escrevendo o post de blog sobre isso e vamos compartilhar mais detalhes em breve
  Se você quer contexto, dê uma olhada na lista de correções de bugs nas notas de versão do Bun v1.3.14 e de releases anteriores
  Rust não vai capturar tudo isso. Vazamentos causados por manter referências por tempo demais e todos os problemas de reentrada atravessando a fronteira com JS continuam sendo nossa responsabilidade
  Mas uma parte considerável dessa lista é de use-after-free, double-free e casos em que se esquecia de liberar memória em caminhos de erro, e essas coisas viram erro de compilação ou limpeza automática

  • Há 9 dias você disse isto[0]:
    I work on Bun and this is my branch
This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
    Talvez não tenha sido exagero?
    [0]: https://news.ycombinator.com/item?id=48019226
  • Estou ansioso pelo post
    Queria saber se vocês planejam rodar os binários de Zig e Rust lado a lado em uma grande variedade de aplicações reais, ou até fazer shadow execution em produção, se possível, para filtrar bugs
  • Se eu fosse cliente pagante, ficaria curioso para saber quanto isso custou
    Dá para passar uma estimativa aproximada?
  • Queria saber se vocês implementaram ou pretendem implementar algum tipo de fuzzing de ponta a ponta comparando os dois binários
    E também qual é o plano concreto para lançar isso sem quebrar os workflows dos usuários
  • Isso tem chance de corrigir os problemas de estabilidade da API Bun Workers? https://bun.com/docs/runtime/workers

• Uns 9 dias atrás o Jarred escreveu que não estava nada claro se isso seria mergeado e que era um exagero
  Irônico

  • Parece um caso exemplar de liderança em open source
    Imagine o tamanho do caos se o Linus dissesse que não ia reescrever o kernel Linux e um dia acordasse e mergeasse o projeto inteiro numa reescrita em Rust assistida por máquina
  • Quando a pessoa deixa de ser dona da empresa, pode ignorar com segurança o que ela diz
    Era óbvio que teriam de justificar o custo em tokens que gastaram
  • Isso também não quer dizer que a possibilidade de merge tivesse sido excluída

• Uau, isso vai ser divertido de acompanhar
  Não há chance nenhuma de esse código ter sido revisado, mas talvez já estejamos entrando numa era pós-humana em que dá para confiar que modelos escrevam e revisem código
  Isso é tipo Gastown, mas acontecendo num projeto muito mais famoso
  Fico curioso para ver como esse projeto vai conseguir adicionar novas funcionalidades daqui para frente, ou se isso sequer será possível
  Alguém sabe exatamente como a Anthropic usa o Bun?
  Faz parte do Claude Code?
  Fico bem preocupado em usar o Bun no futuro, mas não sei até que ponto essa preocupação também deveria se aplicar ao uso do Claude

  • Não significa de forma alguma que dá para confiar que modelos escrevam e revisem código
  • Todos os testes passaram
    Se você não pode confiar no conjunto de testes para detectar tradução automática entre linguagens, então não deveria confiar nele para nada desde o começo :)
  • Não sei como a Anthropic usa o Bun, mas parece que está usando isso para deslocar a janela de Overton da discussão para “tudo bem mergear milhões de linhas sem olhar direito”
  • Em que estado está a suíte de testes?

• Na verdade estou animado com a ideia de experimentar tradução automática, mas preocupado com quantos problemas de compatibilidade retroativa isso vai criar
  Comecei a olhar os commits e, basicamente, o problema de “os testes não passam” está sendo resolvido mudando os próprios testes
  O trabalho real para fazer isso funcionar corretamente em programas já implantados está só começando
  Pelo menos, por algum motivo, a comunidade de JS do lado do servidor já parece acostumada a quebras frequentes

  • A ideia de que no runtime que eu uso vai entrar código que ninguém sequer olhou me deixa desconfortável
    Mas, se isso realmente funcionar na prática sem grandes problemas, vai ser bem impressionante
  • Não sei se foram LLMs que tomaram essas decisões, mas sempre tive a sensação de que o Claude tende mais a ter comportamentos suspeitos como modificar testes em vez de encontrar a solução correta para o problema
    GPT/Codex é mais honesto nesse ponto
  • Não me parece que isso vá virar release estável tão cedo, mas ficarei feliz se provarem que eu estava errado
    Sou cético em relação a esse rewrite inteiro, e Jarred Sumner tem seguidores demais na internet, então isso parece publicidade
  • Exemplo de resolver o problema de “os testes não passam” alterando os próprios testes: https://github.com/oven-sh/bun/pull/30412/changes/68a34bf8ed...
    Excelente! É só adicionar um sleep(1) aleatório nos testes. Relaxa, vai dar tudo certo!
  • Queria vasculhar os testes para ver se houve alguma mudança realmente importante, mas o GitHub nem consegue carregar o diff

• Os poucos projetos meus que usam Bun vão ser migrados para outra coisa
  Não confio numa governança que permite uma mudança imprudente dessas

  • O Deno é excelente, e acho que não recebe o mesmo carinho
    Foi bem escrito desde o começo, então nem precisa de rewrite
  • Eu vou continuar só no node mesmo
    Por outro lado, vai ser interessante assistir ao batismo de fogo, e no longo prazo acho que os problemas acabam sendo resolvidos

• Há um thread que vale ver pelo valor didático. É o thread em que, uma semana atrás, Jarred voltou a se afastar da decisão de merge e uma multidão de soldados de infantaria atacou quem previa que isso seria mergeado em breve:
  https://news.ycombinator.com/item?id=48073680
  Agora não parece que essas falas envelheceram bem, né?

  • De “o thread inteiro é um exagero. 302 comentários sobre código que não funciona. Não decidimos reescrever. Há uma chance muito alta de esse código todo ser jogado fora” para merge completo em 10 dias, incluindo o que parecia ser apenas curiosidade experimental, isso realmente parece insano
  • Sempre me surpreende ver quantos seguidores do poder existem no mundo, sem se importar muito qual bota estão lambendo

• Se isso der minimamente errado, as piadas chamando os caras de traficantes chapados no próprio produto vão ser intermináveis e deprimentes

  • Tem gente demais que não está emocionalmente preparada para a possibilidade de não dar nada errado
  • Ver o código-fonte vazado do Claude Code já não foi munição suficiente para zombaria?
  • Eles já estão chapados no próprio produto
    Você leu o paper do Mythos? O nível de antropomorfização é realmente pesado
    Pode ser só clickbait barato, mas se eles realmente acreditam que LLM tem consciência... uau