Reescrita experimental do Bun em Rust atinge 99,8% de compatibilidade nos testes em Linux x64 glibc

• A reescrita em Rust do Bun passou em 99,8% da suíte de testes existente no ambiente Linux x64 glibc
• A base de código é “basicamente a mesma base de código”, e a migração para Rust permite que o compilador imponha o ciclo de vida dos tipos e use destrutores quando necessário
• As partes inseguras ficam mais explícitas com unsafe em Rust, o que tem o efeito de incentivar refatorações
• O motivo da reescrita foi o cansaço de gastar muito tempo se preocupando e corrigindo vazamentos de memória, crashes e problemas de estabilidade, além do desejo por ferramentas mais fortes na linguagem para evitar isso
• A escala total foi descrita como uma reescrita de 960.000 LOC, e a expectativa é que, após passar na suíte de testes no Linux, outras plataformas também sejam contempladas em breve

---

Estado da reescrita em Rust

• A reescrita em Rust do Bun passou em 99,8% da suíte de testes existente no ambiente Linux x64 glibc
• A base de código é “basicamente a mesma base de código”, e ao migrar para Rust o compilador passa a impor o ciclo de vida dos tipos e a permitir o uso de destrutores no momento necessário
• As partes inseguras aparecem de forma mais explícita como unsafe em Rust, o que ajuda a incentivar refatorações
• O contexto da reescrita inclui o cansaço de gastar muito tempo se preocupando e corrigindo vazamentos de memória, crashes e problemas de estabilidade, além do desejo de que a linguagem oferecesse ferramentas mais fortes para evitar esse tipo de problema
• A escala total foi descrita como uma reescrita de 960.000 LOC, e o código de fato funciona, passa na suíte de testes no Linux e outras plataformas também devem entrar na mira em breve

Próximas divulgações e respostas sobre build

• O significado disso para o Bun, benchmarks, uso de memória, manutenibilidade futura e o processo real da reescrita serão tratados em um post de blog separado
• O processo de reescrita não foi simplesmente dizer “claude, rewrite bun in rust. make no mistakes”, e o trabalho para chegar a um estado funcional até o fim começou há 6 dias
• Foi dito que, se tivesse sido totalmente manual, teria sido uma quantidade enorme de trabalho
• O tempo de compilação é basicamente semelhante ao da versão atual em Zig, que usa um compilador Zig mais rápido, e foi dito que, se tivesse sido usado o compilador Zig upstream, o port para Rust teria compilado mais rápido
• O desempenho será tratado em um post de blog separado
• Sobre a próxima etapa de substituir a própria libc pela versão em Rust frankenlibc, foi dito que antes disso a ideia é criar uma libc própria

[GN⁺]

Comentários do Hacker News

• Já tinha algo sobre isso 4 dias atrás: https://news.ycombinator.com/item?id=48019226
  Um desenvolvedor do Bun disse que era o branch dele, que o tópico da época era uma reação exagerada a um código que não funcionava, que ainda não tinham decidido por uma reescrita e que havia grande chance de o código inteiro ser descartado
  Ele disse que queria ver como seria uma versão funcional, como ficariam desempenho e manutenibilidade, e quão difícil seria passar a suíte de testes do Bun para comparar a versão em Rust e a versão em Zig lado a lado

  • Quando ele escreveu aquela mensagem, cargo check retornava mais de 16 mil erros do compilador, e não conseguia nem imprimir a versão nem executar JavaScript
    Ele não imaginava que funcionaria tão rápido, nem que o desempenho seria tão competitivo, e disse que mais detalhes viriam em um post no blog
  • Parece que tomaram a decisão depois de avaliar manutenibilidade, desempenho e a suíte de testes
  • Nesse caso, até agora isso significa que foi muito bem-sucedido como experimento
  • Alguns dias atrás ele também disse: “o open source parece que vai seguir na direção oposta. Proibição de contribuições humanas. Slop vai ser uma relíquia nostálgica de 2025~2026”
    Eu devia ter esperado isso depois da aquisição pela Anthropic, mas ainda assim é decepcionante. Não sou contra a tecnologia de modelos de linguagem em si, mas a forma como essas empresas de “IA” vêm engolindo a indústria de software e a sociedade em geral para ganhar poder é repugnante, e está criando uma dependência muito pouco saudável
    É preciso pensar algumas jogadas à frente e preparar uma pilha de software e uma comunidade sem slop. Isso inclui o Zig e seu ecossistema. Mesmo que nós e as gerações futuras não consigamos viver completamente sem slop, garantir uma cultura de computação sustentável, com liberdade como liberdade, é mais importante do que nunca

• É muito impressionante terem feito isso tão rápido. Estou há 5 meses num projeto parecido de portar TypeScript para Rust, mas sem Mythos nem acesso ilimitado a tokens
  Mesmo assim, já cheguei perto de quase 100% de aprovação e, no momento em que escrevo, está em 99,6%: https://tsz.dev
  Rust é muito adequado para escrever código com modelos de linguagem. Graças ao sistema de tipos rígido, você comete menos erros muito idiotas que outras linguagens deixariam passar
  Dito isso, escrever código com modelos de linguagem não elimina a necessidade de visão de projeto e de julgar trade-offs ao criar um projeto. Por isso Jarred e a equipe são as pessoas certas para aproveitar e escrever uma quantidade enorme de código com modelos de linguagem

  • A imposição de invariantes em tempo de compilação do Rust ajuda modelos de linguagem a obter feedback rápido e voltar atrás, então isso ajuda a gerar código funcional
    Por outro lado, Rust é uma linguagem complexa, então pequenas mudanças podem facilmente provocar uma avalanche de refatoração que força refactors em código distante. Se a arquitetura inicial for ruim ou insuficiente, há um grande risco de o código virar espaguete conforme o modelo vai aumentando a base de código incrementalmente, como costuma fazer
    No fim, temo que isso produza programas que compilam e até rodam, mas que humanos não conseguem ler nem manter
  • De forma parecida, também estou fazendo Postgres multithread. Em 1 mês já passou em 96% dos testes de regressão do pg e chegou a 823K LOC
    Isso foi tudo que deu para fazer sem Mythos, usando 8 contas do Codex de US$ 200 por mês
    Também vi as vantagens do Rust aqui e, com base na minha experiência com Postgres, acredito que dá para tomar boas decisões de design em várias áreas que há muito tempo são difíceis no pg. Estou animado com o fato de que a IA pode tornar mais viáveis melhorias em softwares complexos que antes não eram práticas
    [0] https://github.com/malisper/pgrust
    [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
  • Quando a Microsoft reescreveu isso em Go, uma das líderes citou a similaridade de paradigma como motivo para escolher Go em vez de Rust. Disse que coisas como garbage collection eram parecidas e que Rust seria mais difícil e exigiria muito mais contornos. Fico curioso para saber como isso soa para quem fez na prática
  • Rust é excelente, mas, em projetos grandes, quando você tenta construir software em Rust com modelos de linguagem, ele desmorona do jeito que você quer
    Até manter ou estabelecer limites limpos deixa de ser um estado de fluxo e vira uma revisão dolorosa, e no fim você cai no modo de procrastinação
  • Tive trabalho para fazer o Opus parar de ignorar os idiomatismos de Rust e de escrever o Rust mais estranho possível. Queria saber se alguém tem dicas

• Não tenho base fortíssima para isso, mas não quero mais me envolver com o Bun. É mais intuição, mas não consigo confiar nem apoiar
  Forkaram o Zig para tentar aproveitar uma reescrita com LLM e criaram coisas como compilação não determinística, que a equipe do Zig claramente rejeitava
  Agora estão fazendo uma reescrita com LLM em Rust de forma meio chorosa. Talvez Bun tenha chegado até aqui justamente porque a filosofia de design do Zig forçava decisões difíceis, porém corretas, e a reescrita em Rust possa de fato ser o começo da decadência
  É um julgamento mais político do que técnico, mas o Bun parece totalmente escorado no Claude. Eu não me surpreenderia se o próximo slogan de marketing da Anthropic fosse “Claude Mythos reescreveu em Rust um runtime JS líder com 950K LOC”

  • Não sei se o chorão é o desenvolvedor escrevendo código no próprio repositório ou a pessoa no Hacker News reclamando disso
  • Não vi o Jarred choramingando, e parece que essa emoção está mal direcionada
    O fio do Twitter linkado apresenta fundamentação técnica clara
  • Não sou tão investido pessoalmente no Bun, mas não vejo por que isso importa. Fico curioso se você examina outras dependências desse jeito
    Trabalhar no ecossistema JS/NPM já é depender bastante de pura fé em dependências não verificadas, e não vejo tanta diferença antes ou depois de uma reescrita com LLM. Se satisfaz o objetivo original e o contrato da API, faz diferença? Também duvido que você estivesse lendo o código-fonte anterior com tanto cuidado assim
  • Concordo. O Bun sempre teve uma filosofia de design clara desde o começo. Era fazer tudo o que quisesse: runtime, bundler, suíte de testes, gerenciador de pacotes, e lançar patch que quebra toda semana
    Sempre naquela lógica de superar a concorrência existente sendo melhor, mais rápido e mais forte, mas era óbvio demais que Keep It Simple Stupid era a única coisa que jamais fariam
    Também era evidente que, no futuro próximo, os únicos lugares onde isso apareceria em produção seriam startups da YC queimando uma a uma como se tivessem jogado acelerante. Agora parece que já passou do ponto de retorno
  • O Bun está praticamente morto
    A Anthropic comprou o Bun numa tentativa meio burra de resolver os próprios problemas de “desempenho”. Pelo visto não perceberam que o problema desde o início era código ruim
    Ainda assim, trouxeram desenvolvedores realmente competentes, então isso pode ter ajudado em alguma medida
    Mas, nesse processo, o Bun deixou de ser um projeto público para virar algo mais próximo de uma ferramenta interna da Anthropic, e agora está bastante sem foco, superprotegido por dinheiro de IA
    Espero que, quando a bolha estourar, ainda dê para salvar pelo menos parte do esforço colocado no Bun. Não parece que a Anthropic vai manter isso no longo prazo. Eles não são uma empresa que vende suporte de runtime, nem têm escala de Google para manter um runtime como atividade paralela

• Tirando a questão da IA por um momento, acho que seria uma boa mudança
  O Bun tinha muitos crashes e bugs de memória usando Zig, ao contrário do Deno, que é baseado em Rust
  Claro, se o port do Bun para Rust tiver muito unsafe, isso não vai se resolver por mágica, mas ainda assim deve melhorar

  • Gostaria de saber se existe alguma estatística ou fonte para dizer que o Bun tem muitos crashes e bugs de memória. Não acho que esteja errado
    O fato de as partes feias ficarem mais explícitas com unsafe, induzindo refatoração, parece não ser só uma questão da linguagem; também parece algo que o próprio Bun causou em certa medida
  • A alegação é que usar Zig “aumenta muito a quantidade de crashes e bugs de memória”?
    Se for isso, então não significaria que fazer software de alta qualidade com essa ferramenta é praticamente impossível? Muita coisa de qualidade foi feita em C/C++, então fico me perguntando o que exatamente o Zig estaria fazendo de errado
  • Como fica claramente marcado com unsafe, é mais fácil de encontrar, e naturalmente surge uma lista de problemas que precisam ser resolvidos

• Isso levou 6 dias. Mesmo que no fim não resulte em algo significativo, mostra como tokens e volume de trabalho estão ligados agora e no futuro
  Vai ficar mais difícil competir com pessoas ou empresas que tenham mais recursos computacionais. Elas simplesmente vão conseguir fazer coisas que eu não consigo

  • É bem conhecido que traduzir um projeto de uma linguagem para outra, quando existe uma boa suíte de testes, é um caso em que modelos de linguagem vão muito bem
    Se você pode usar uma base de código pronta como exemplo e validar com uma suíte de testes, fica muito mais fácil iterar em direção ao objetivo desejado. O modelo já consegue ver qual é o objetivo e como ele já foi implementado uma vez, então é um problema muito mais fácil do que partir de uma especificação
  • Também dava para dizer o mesmo sobre a força a vapor ou a eletricidade. E nem é só analogia simples. A magia dessas coisas está em serem motores de informação de uso geral
    Você investe capital, usa uma técnica escalável e bem compreendida, liga na tomada e sai valor
    O ponto é que, assim como a eletricidade não virou isso no mundo moderno, não parece provável que exista essa divisão entre “quem tem” e “quem não tem”
  • Não é claro. Produtos realmente bons em geral surgem de fazer uma ou duas coisas muito bem, e não muitas coisas
    O que temos visto até agora é “uau, agora sou um engenheiro 10x!”, despejando mais código, mas sem direção nem gosto claros. Grande parte do trabalho atual baseado em modelos de linguagem parece só ruído
  • Não. Esses agentes estão cada vez mais fáceis de rodar localmente
    Não sei se você já testou o Qwen 3.6 27b, mas é insano o que ele consegue fazer para o tamanho que tem. Se você gerenciar bem o contexto, até dá para fazer projetos pequenos com 100% de vibe coding
    Esses modelos também devem cair para uma guerra de preços no fim, como aconteceu com computação
  • Fico curioso sobre quanto isso teria custado em dólares se fosse pago na tabela padrão da Anthropic. Alguém consegue estimar, nem que seja por alto?

• Muita gente está aceitando isso pelo valor de face, mas uma parte considerável disso só foi possível graças a uma suíte de testes ampla e abrangente, muito acima do padrão, construída antes

  • Ainda assim, é impressionante, porque mesmo o engenheiro mais competente teria levado muito mais tempo para chegar a esse resultado
    Quando forem fazer marketing disso depois, seria bom mencionar também quanto esforço humano entrou no design e na curadoria da suíte de testes que tornou essa velocidade possível
    Suítes de testes funcionam quase como um ambiente ideal para os modelos de linguagem da geração atual. Uma suíte de testes suficientemente abrangente vira uma especificação que o agente pode implementar da forma que quiser; aqui, no caso, o alvo era Rust
    Em projetos com testes tão bem-feitos quanto o Bun, em alguns casos parece até que seria possível jogar fora todo o código-fonte real, dar acesso só aos testes e ainda assim reimplementar tudo do zero
  • Se isso é uma suíte de testes tão “acima do padrão” a ponto de tornar esse trabalho singularmente possível em comparação com outros projetos, então fico me perguntando como isso se concilia com a ideia de que o Bun seria excepcionalmente instável entre programas em Zig e precisaria de reescrita
    Se a responsabilidade também recai em parte sobre a suíte de testes, fico curioso sobre o que isso significaria para o port em Rust
  • Então é para olhar só para o fato de que conseguiram fazer isso em 6 dias
    E ignorar as centenas de milhares de horas investidas na arquitetura original e na suíte de testes que tornaram isso possível?

• Vale ver isso como um caso de advertência sobre portar para Rust com IA
  https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...

  • Passar nos testes não significa necessariamente funcionar
    O compilador C do Claude code passou em 100% dos testes do gcc, mas não conseguia nem rodar hello world
  • A lição a tirar desses casos é um pouco diferente. Modelos de linguagem constroem com base no loop de feedback que você fornece
    Se você só der testes de lógica, eles não vão considerar velocidade nenhuma. Se você incluir testes que medem velocidade e pedir que atinjam o desempenho, eles também vão fazer isso
    É o mesmo tipo de erro que outros erros de modelos de linguagem. Eles não têm contexto de senso comum sobre o que humanos consideram importante. Se você não impuser limites, eles ignoram
  • Se interessar, isso foi discutido aqui: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - março de 2026, 422 comentários

• É impressionante estar vivo nesta época
  A dinâmica fundamental da indústria e da profissão mudou em tão pouco tempo, praticamente da noite para o dia
  Em alguns dias fico empolgado com o tanto de coisa que agora consigo fazer. Posso construir quase imediatamente qualquer coisa que eu queira, e 100% do que eu sonhava em software pode se tornar realidade
  Em outros dias fico com medo do que vai acontecer com o mercado de trabalho
  De repente, ficou possível obter muito com muito pouco, e a quantidade de software de que o mundo precisa tem limite
  Será que toda empresa cujo modelo central de negócio é vender software vai quebrar?
  E se só empresas ou governos específicos tiverem acesso aos melhores modelos?

  • Pense em um negócio de software como um sistema de bilhetagem
    Será que 100 empresas com 1 bilhão de tokens vão conseguir fazer um produto melhor do que um fornecedor especializado com 100 bilhões de tokens?
    É verdade que fornecedores de software e SaaS tipo “gerador de logo” já morreram, mas, a menos que a próxima geração de modelos de linguagem venha com um sistema de bilhetagem embutido, os fornecedores desse tipo de sistema devem ficar bem. O quadro de pessoal pode encolher, mas não é certo
  • Perto do estouro da bolha pontocom, também havia bastante discurso de que a indústria de software estava “saturada demais” e que estudantes e pessoas procurando emprego não deveriam entrar
    A ideia era que havia pouco trabalho para dividir diante da quantidade de gente entrando, e o colapso reforçou essa narrativa
    Mas mesmo sendo estudante na época já dava para perceber que o escopo do software era praticamente infinito. Quase todo trabalho cognitivo que fazemos manualmente pode ser feito por software. Uma vez tentei listar essas coisas e logo percebi que havia trabalho demais
    Além disso, eu entendia que, conforme fazemos as coisas de maneiras novas, surgem ainda mais tarefas que antes eram inimagináveis. As possibilidades eram incontáveis, e essa narrativa de “saturação” claramente vinha de falta de imaginação e de entendimento sobre o que é software
    Então eu sabia que essa área nunca ficaria saturada. Era impossível esgotar as coisas que poderiam ser feitas com software
    Mas hoje parece diferente. Continuaremos criando software novo, mas agora me pego pensando se talvez a velocidade com que escrevemos software possa superar a velocidade com que conseguimos imaginar coisas novas para ele fazer
  • Empresas e governos vão ter acesso a modelos melhores do que o público. Na prática, Mythos já é um exemplo disso
    O público ainda poderá se ajudar com modelos atrás da fronteira de ponta

• No mínimo, é interessante ver uma tentativa dessas acontecendo
  A primeira coisa que me desperta curiosidade é quão abrangente e de qualidade é a suíte de testes para começo de conversa. Não é para desmerecer, mas me pergunto quanta confiança a equipe do Bun teria numa migração dessas mesmo se desse 100% em todas as plataformas

• Depois do caso do Ubuntu coreutils na semana passada, fiquei com uma impressão realmente péssima de reescrita em Rust com 99,8% de compatibilidade de testes
  Cliquei no tweet linkado aqui e senti um arrepio, e agora esse tipo de coisa me provoca exatamente a reação oposta. Quase me faz procurar a saída