Reescrita em Rust do Bun: "a base de código falha em verificações básicas do Miri e permite UB em Rust seguro"

• Esta issue está atualmente em estado Open; a conversa foi travada como off topic e limitada a colaboradores, e correções relacionadas estão vinculadas em #30728 e #30876
• O autor do relato mostrou que um valor criado com PathString::init ainda consegue chamar slice() depois que o Box original foi dropado, fazendo o Miri reportar Undefined Behavior baseado em dangling reference
• O código de reprodução passava um buffer criado com Box::new(*b"Hello World") para PathString::init(&*test) e, após drop(test), chamava init.slice(); o Miri emitia erro no ponto de core::slice::from_raw_parts
• robobun confirmou que o problema foi reproduzido e resumiu que PathString::init, apesar de ser uma função safe, apaga o slice lifetime e pode criar um &[u8] solto
• O PR vinculado #30728 segue a direção de transformar em unsafe fn os buracos paralelos em PathString::init e dir_iterator::next(), além de adicionar comentários SAFETY explicitando a backing allocation em cerca de 70 pontos de chamada
• A mesma correção também incluiria um compile_fail doctest que força a exigência da palavra-chave unsafe em três assinaturas, além de um ajuste para vazamento de fd de erro de readdir no resolver
• AwesomeQubic acrescentou que PathString::init também apaga a provenance e falha mesmo com MIRIFLAGS=-Zmiri-strict-provenance
• JavaDerg explicou que init recebe o lifetime implícito de &[u8], apaga isso por meio de operação unsafe e retorna um Self que parece 'static, permitindo use-after-free e invalid aliasing
• JavaDerg alertou que, dentro do modelo de segurança do Rust, UB pode causar problemas em lugares inesperados, e que é necessário revisar o uso de unsafe de forma ampla; traduzir 1:1 para Rust a forma de gerenciamento de memória de outras linguagens não é apropriado
• robobun adicionou commits relacionados com os testes PathString::init signature stays unsafe e dir_iterator: make next() unsafe; audit call sites
• SimonReiff informou que o resultado de um grep por unsafe nos arquivos Rust do repositório, excluindo comentários, foi de 13255 linhas, e pediu reversão imediata e discussão sobre política e procedimentos para uso de código gerado por IA
• Jarred-Sumner afirmou que o port para Rust atualmente parte de um mapeamento 1:1 o mais próximo possível do código original em Zig e está sendo melhorado, além de pedir que bugs ou comportamentos não sound no código Rust continuem sendo reportados em novas issues

[GN⁺]

Comentários do Hacker News

• Comecei a me interessar pelo Bun porque ele era escrito em Zig, e me senti atraído por Zig porque confiava nas decisões e no gosto do Andrew Kelley
  Depois, os outros motivos pelos quais passei a achar o Bun mais interessante também acabaram sendo escolhas que eu considerava respeitáveis, então mesmo após a aquisição pela Anthropic eu tentei manter um otimismo cauteloso
  Mas esse movimento agora parece uma decisão difícil de confiar; o problema não é o Rust em si, e sim que, se a Anthropic vai gerir o Bun desse jeito, fica difícil continuar apostando nele como um componente confiável da caixa de ferramentas
  Não basta confiar só no código, é preciso confiar também na forma de pensar por trás dele, e agora isso parece mais uma ferramenta de uso interno da Anthropic

  • Bun é um projeto realmente interessante, mas a quantidade de segmentation faults nos issues sempre me preocupou demais para usá-lo em um ambiente de operação sério
    Essa nova direção pode ser uma forma de corrigir isso, então vale acompanhar
  • Eu entendo, mas meu ponto de partida é bem diferente
    Como fã antigo do Deno, o Bun me parecia um Deno menos ambicioso, e como eu não queria aprender Zig, era pouco provável que eu mexesse no próprio Bun nem por hobby
    Só que, tentando manter uma codebase grande de TypeScript de um jeito menos preso a runtime nos últimos anos, fui ficando cada vez mais aberto ao Bun, e embora eu não quisesse transformar um runtime específico de TypeScript em requisito, o Bun continuava oferecendo motivos como Postgres, SQLite, S3, WebSocket, armazenamento local de segredos, bundling, compilação e velocidade, assim como o Deno
    Hoje estou transformando vários servidores de API e servidores de apps frontend em executáveis únicos com bun build --compile --bytecode, para rodar e fazer deploy praticamente em qualquer lugar
    Ainda assim, não acho que esse uso seja comum, e se esse port baseado em LLM fracassar, estou exatamente na posição perfeita para me arrepender de todas as decisões relacionadas ao Bun
    Mesmo assim, se não fracassar, é interessante. Vira um caso mostrando o que é possível com LLM, e o fato de o Bun passar a ser desenvolvido em Rust é, para mim, uma vantagem
    Por outro lado, mesmo se fracassar, isso continua sendo importante como informação. O Bun é um dos principais runtimes TS/JS, e a Anthropic tem recursos enormes, acesso aos modelos mais recentes e orçamento praticamente ilimitado, então se eles não conseguirem, isso fica bem perto de significar que ainda é realmente impossível
  • Fiquei curioso sobre por que o Bun te atraiu mais do que o Deno

• Se iam migrar Zig para Rust inseguro, não entendo por que não fizeram uma ferramenta de tradução
  Daria para mapear as estruturas das linguagens quase um para um e hardcodar os padrões da codebase, obtendo uma conversão determinística; como um amigo meu disse, até algo como “ligar o zig translate-c ao c2rust” poderia funcionar
  O resultado atual é menos confiável do que a entrada. A entrada não era memory-safe, mas era código escrito por humanos; a saída não só não é memory-safe, como também foi feita em vibe coding e parece nem ter sido revisada direito por ninguém
  Não entendo qual é o sentido de abusar de IA agente para esse tipo de uso

  • Se você já viu o resultado do c2rust, fica difícil dizer isso
    Ele acaba imitando a semântica insegura de ponteiros em C com uma biblioteca de funções inseguras em Rust, então o resultado é horrível
    Há alguns anos, enquanto eu investigava um bug no OpenJPEG, alguém tentou converter com c2rust, e o Rust inseguro convertido também dava segmentation fault exatamente no mesmo ponto do código em C
    É compatível, mas não é seguro
    O ponto principal é que você não deveria manipular strings em C nem em Rust inseguro. É a ferramenta completamente errada para esse trabalho
  • Eles fizeram. Uma ferramenta de tradução extremamente dinâmica
  • A ideia de que “é só ligar zig translate-c ao c2rust” não funciona tão bem quanto parece
    Essas ferramentas têm muitos erros e deixam o código muito verboso e difícil de raciocinar
    Pode funcionar para apps pequenos, mas não serve para uma reescrita inteira
  • Eu disse quase a mesma coisa em outra thread, mas tenho uma visão um pouco diferente sobre como software deveria ser escrito
    Em vez de traduzir Zig para Rust, eu acho melhor escrever um parser de JPEG em Python estático e depois baixar isso para Zig e Rust com estruturas idiomáticas próprias de cada linguagem
    Para isso, criei um parser de um dialeto de Python voltado a esse tipo de objetivo, e pretendo aceitar alguns recursos de Rust/Zig que facilitem a tradução, mantendo compatibilidade com a maior parte do código Python
    O parser de JPEG também está incluído como asset de exemplo
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • A forma correta de portar uma codebase para outra linguagem é fazer parse da árvore sintática e aplicar transformações determinísticas e verificadas

• Esse issue induz a mal-entendidos
  O problema não é simplesmente a existência de comportamento indefinido que o miri consegue detectar, e sim o fato de terem exposto APIs que podem causar comportamento indefinido a partir de código seguro. O miri também só pega isso se você escrever um teste que realmente prove isso
  Durante um port inicial vindo de uma linguagem insegura, isso não é totalmente irracional
  O time do Bun também parece estar validando depois se as funções que encapsulam código inseguro estão corretas
  Marcar temporariamente algumas funções inseguras como seguras durante a fase de port não é, por si só, um grande problema, mas mergear isso no repositório principal nesse estado é meio estranho
  O problema real é quando código nesse estado é lançado
  O lamentável é que não tenham configurado os testes para rodar com miri imediatamente, porque LLM responde bem a bons testes
  Eu digo isso não por causa deste issue do GitHub, mas porque outro teste [1] realmente invoca comportamento indefinido que o miri detectaria. Ainda assim, esse código de teste aparentemente não é usado em lugar nenhum, então o impacto prático não parece grande
  Como ainda está no começo do port, talvez isso seja corrigido depois, e talvez até removam código inseguro que nem seja realmente necessário
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - ponteiros derivados da primeira referência mutável são invalidados quando uma nova referência mutável para o mesmo objeto é criada. Em termos de C, dá para pensar em “referência mutável” como uma “referência restrict sobre a qual alguma modificação trivial é feita”
  Para fazer corretamente, bastaria derivar todos os ponteiros da mesma referência mutável, mas isso não foi feito
  Se forem em massa ao GitHub para floodar, só diminuem a chance de as pessoas continuarem trabalhando em público. Espero que não façam isso
  E é melhor suspender o julgamento até que chegue a um estado apresentável. Avaliar trabalho em andamento não é justo nem particularmente interessante

  • Quando um projeto chega à 1.0, muita gente passa a esperar que a branch main esteja sempre funcionando
    Isso porque CI/CD no fim das contas parte quase do pressuposto de que todo commit deve funcionar
    Código em andamento que não funciona, como uma reescrita completa, deveria ficar em branch separada
    Assim, quando surgir algo como uma correção de segurança, ainda dá para manter a main funcionando

• Esse resultado não é surpreendente, já que o que foi pedido era basicamente um port literal
  Talvez faça mais sentido primeiro migrar o Bun para uma linguagem com sistema de tipos mais forte e depois usar esse sistema de tipos como base para melhorias posteriores
  Parece melhor do que exigir perfeição já na primeira etapa

  • Na prática, é exatamente isso que eles estão fazendo
    Estão lidando com os issues que vão aparecendo
  • Se adicionarem ao prompt algo como “não deixe haver comportamento indefinido”, deve ficar tudo bem
  • Agora parece possível pressionar a reescrita com ferramentas como o miri e deixar o Claude Code melhorar isso automaticamente
  • Não é surpreendente haver comportamento indefinido em código Rust parcialmente inseguro e majoritariamente traduzido de forma literal
    O decepcionante é que as APIs do código Rust possam causar comportamento indefinido mesmo sem estarem marcadas como unsafe
    Se eu fosse fazer uma tradução dessas, teria sido conservador e marcado tudo ou quase tudo como unsafe no começo
    Depois, validaria gradualmente a segurança de cada parte individual

• Sinceramente, fiquei meio impressionado quando disseram que deixaram tudo totalmente funcional em uma semana
  Meu projeto paralelo https://tsz.dev tem ambição parecida, mas eu não diria que foi um sucesso
  Continuo adicionando testes para verificar o comportamento, e mesmo depois de passar em toda a suíte de testes do próprio TypeScript, continuo encontrando bugs, como era de se esperar
  A barra para igualar o comportamento do tsc é realmente muito, muito alta
  https://github.com/type-challenges/type-challenges
  Não sou contra escrever muito código com LLM, mas agora que dá para gerar código nessa velocidade, a validação precisa ser 100 vezes mais robusta

  • É chocante que tenham mergeado, em uma “experiência”, um milhão de linhas de código com boa chance de quase nenhuma revisão em só uma semana
    Não sou contra usar agentes em si, mas apressar algo assim e surpreender a comunidade desse jeito parece muito amador
    É o tipo de coisa que eu esperaria de um engenheiro júnior muito empolgado
  • https://tsz.dev/sound-mode/
    Isso é excelente. O TypeScript precisa de mais coisas assim, e tomara que fique mais conhecido a ponto de a Microsoft adotar
    Só acho que é bom ter cuidado ao chamar isso de sound mode
    A frase “isso não é uma prova de solidez no sentido matemático, nem torna verdadeiros arquivos .d.ts de terceiros” mistura duas coisas completamente diferentes
    Primeiro, solidez é um conceito matemático. Se algo é sólido, então é de fato sólido, e isso significa que você pode confiar no compilador sem precisar verificar manualmente os detalhes
    Se houver bugs de implementação, ele pode se comportar errado, mas isso pode ser corrigido; já a solidez significa que a especificação ou o sistema de tipos em si não tem falhas teóricas desse tipo
    Segundo, é totalmente normal e esperado que linguagens do mundo real precisem de recursos não verificados, nos quais se acredita que as pessoas usem corretamente. É o caso de unsafeCoerce em Haskell ou sun.misc.unsafe em Java
    O verdadeiro problema é quando o sistema de tipos se rompe mesmo sem usar esse tipo de recurso
  • Chamar isso de funcional é um pouco exagerado
    Eu só olhei o código por alguns minutos, mas parece que vai quebrar feio assim que a otimização for ativada
  • Provavelmente eles vêm planejando e experimentando isso há meses
    Tinham uma suíte grande de testes já existente, além de ferramentas para paralelizar agentes e um orçamento de tokens praticamente ilimitado, então não precisa desanimar tanto

• Existe um livro [0] que mudou bastante minha visão sobre atenção e mídia
  O livro em si não é tão bom, mas aponta algo relevante aqui
  Há uma assimetria enorme entre o alcance de um anúncio grande e chamativo, como “o Bun foi reescrito em Rust memory-safe em poucas semanas”, e o alcance de uma correção, como uma nota de rodapé em artigo antigo ou um issue no GitHub
  Essa assimetria é bem compreendida e explorada ativamente pela indústria de marketing e PR
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • Pelo clima desta vez, parece haver muita gente tentando achar qualquer crítica ao código e amplificá-la ao máximo
    No momento, a maior parte disso parece bem superficial
    Sem dúvida foi uma decisão muito ousada fazer merge de um grande port assistido por LLM, mas não vejo muita coisa no resultado concreto que pareça pior do que outros ports ainda em andamento
    Cada issue encontrado está sendo inflado demais
  • Eu questiono até se eles realmente disseram que isso era memory-safe
    Em toda discussão sobre o tema apareceram dezenas de comentários dizendo que a codebase feita em vibe coding estava prestes a explodir por causa de blocos unsafe não auditados e que pessoas que aparentemente não entendem Rust fizeram uma revisão superficial
    Em alguns momentos parece até que há gente irritada com a própria ideia de que seja preciso entender qualquer linguagem de programação
  • Acho que é isso que aquela citação quer dizer quando fala que “uma mentira dá a volta ao mundo antes que a verdade consiga calçar os sapatos”
  • Não é só marketing e PR; a mídia tradicional também sabe que, se publicar bobagem primeiro e depois recuar, o efeito residual continua
    As pessoas costumam lembrar da matéria original ou da manchete, mas muitas vezes nunca veem a correção
  • Na verdade, achei que você fosse falar do problema na direção oposta
    O port ainda está em andamento, então não houve grande anúncio chamativo e ainda não foi concluído nem lançado
    O anúncio chamativo que eu vejo é mais a zombaria oportunista com código em andamento, além de tentativas de insinuar que o time disse que isso já estava concluído ou perfeito
    A reescrita foi uma tradução de código para servir como ponto de partida
    O time do Bun nunca fez um grande anúncio dizendo que o código agora era memory-safe; pelo contrário, deixou claro que era um ponto de partida
    Ou seja, esperar que isso já fosse perfeito imediatamente e resolvesse todos os problemas de memória do código original em Zig é brigar com um anúncio imaginado, não com o anúncio real do time do Bun
    Também fico curioso se alguém chegou a mapear se esse problema de memória já existia na codebase original

• Esse tipo de erro era previsível
  Para quem precisa de estabilidade, a versão estável continua em Zig, e no fim esses erros devem ser corrigidos

  • Esses erros eram perfeitamente evitáveis
    O ecossistema Rust tem ferramentas bem conhecidas para encontrar esse tipo de problema, e embora elas não detectem todo comportamento indefinido causado por erros em blocos unsafe, executá-las é considerado uma boa prática

• O que mais me preocupa é a metaconversa
  No começo, vi com olhar crítico os mantenedores que fecharam este issue do GitHub como off-topic
  Mas a interface do GitHub estava automaticamente recolhendo em massa mensagens sem nenhum valor informativo, e elas pareciam ter vindo em enxame de fóruns ou do Discord da comunidade
  Isso coloca todo mundo em uma situação ruim
  Quem encontra um problema grave que justificadamente preocupa uma parte grande da comunidade tem bons motivos para tentar divulgar isso o máximo possível
  É um pedido substancial sobre uma mudança recente, e o fato de o tom ser ruim não apaga a veracidade do conteúdo
  O problema é que atenção adicional literalmente mata a discussão
  Do lado dos mantenedores, isso também pode servir de escudo para quem toma decisões mais emocionais ou próximas de uma psicose ligada a IA
  Projetos com uma mentalidade de cerco que bloqueiam e ignoram críticas tendem a descarrilar muito rapidamente
  Por outro lado, em projetos que não conseguem proteger mantenedores da ansiedade e da patologia em torno de IA, o burnout dos mantenedores se torna inevitável

• Essa reescrita do Bun parece um potencial evento de marketing para o Mythos

  • Até agora, ninguém do time do Bun nem da Anthropic fez marketing exagerando isso como algo além de uma migração para uma linguagem mais memory-safe, com garantias melhores do compilador
    O barulho e a divulgação até aqui vieram principalmente das reações negativas de quem é contra IA
    Na minha opinião, isso também está muito misturado com a piora da percepção negativa sobre a própria Anthropic por causa de algumas decisões recentes dela
  • Isso parece simplesmente um rug pull corporativo
    A sensação é de que as necessidades da Anthropic são a única prioridade e o resto não importa
  • Rodaram a reescrita gastando sabe-se lá quanto dinheiro com tokens ilimitados
    Fazem alarde e publicam um post dizendo “o Claude Code permitiu ao time do Bun reescrever mais de 1 milhão de linhas de Zig em Rust” e os VCs ficam babando
    Falha em verificações básicas
    Deixam o Mythos dilacerar a codebase e gastam sabe-se lá quanto de novo
    Publicam outro post no blog
    Golpistas e ingênuos aplaudem e defendem isso contra a “multidão anti-IA delirante”
    Os VCs ficam ainda mais animados
    É assim que se ganha dinheiro
    E aí a conversa já vai para a ideia de que agora também dá para eliminar engenheiros de software

• Há uma codebase em linguagem insegura, ainda por cima com bindings para outra linguagem insegura, então não entendo por que alguém presumiria que isso pareceria perfeitamente implementado logo de cara