Bun 1.4 Rust rewrite não está com boa aparência?
As preocupações estão aumentando sobre a reescrita do Bun 1.4 em Rust e sua forte dependência de codificação assistida por IA, já que metas de lançamento repetidamente perdidas e uma cadência de lançamento estável estagnada abalaram a confiança de alguns primeiros adotantes. Os apoiadores rebatem que as builds canary já estão em produção em empresas como Anthropic e Prisma, argumentam que reescritas em grande escala naturalmente são turbulentas e veem isso como uma prova de conceito promissora para o desenvolvimento orientado por LLMs. O debate envolve não apenas a estabilidade e o roadmap do Bun em comparação com alternativas como Node e Deno, mas também se o código gerado por IA pode de fato sustentar infraestrutura crítica.
Sentimento geral sobre Bun 1.4 e a reescrita em Rust
- Alguns usuários dizem que o Bun tem sido “incrível” na prática (rápido, com ferramentas integradas, DX mais agradável) e estão otimistas de que a reescrita em Rust melhore a segurança e os vazamentos.
- Outros relatam instabilidade constante: falhas aleatórias de build, vazamentos de memória e regressões que apagaram qualquer economia de recursos, fazendo-os se arrepender de adotar o Bun para projetos “sérios”.
- Alguns estão usando a canary do 1.4 (reescrita em Rust) em produção e relatam que basicamente funciona, com pequenos problemas (por exemplo, falhas de renderização no REPL).
Cadência de lançamentos, “não está sendo lançado” e comunicação
- Uma preocupação central: os lançamentos antes frequentes do Bun ficaram parados por ~3 meses durante a reescrita em Rust, depois de um histórico de cadência de 2–3 semanas.
- Críticos argumentam que repetidas declarações públicas otimistas no estilo “lança amanhã”, seguidas de atrasos, minam a confiança e sugerem problemas com a reescrita.
- Defensores dizem que uma grande reescrita naturalmente pausa os lançamentos; cautela e polimento antes de uma grande versão são razoáveis.
- Há frustração porque builds canary estão em uso pesado no mundo real (por exemplo, por grandes usuários), mas nenhuma versão estável oficial apareceu por muito tempo, bloqueando a adoção em ambientes conservadores.
- Perto do fim da discussão, as pessoas observam que o 1.4 de fato foi lançado.
Qualidade do código, código morto e métricas
- Uma linha de ataque cita grandes volumes de PRs abertos e alegações de código morto como evidência de que a reescrita “não está com boa aparência”.
- Outros chamam isso de argumento fraco ou enganoso:
- Diz-se que 5k+ PRs abertos não provam declínio na qualidade.
- O exemplo de “11k linhas de código morto” é corrigido: essa remoção se aplicava à base de código Zig mais antiga, não ao port em Rust.
- Alguns argumentam que <1% de código morto em um projeto com um milhão de linhas seria aceitável; outros dizem que código morto deve ser zero e que linters existem para isso.
Node, Deno e alternativas
- Alguns perguntam por que é necessário qualquer alternativa ao Node; eles citam a biblioteca padrão crescente do Node, o test runner, suporte a TS e suporte a arquivos de ambiente.
- Defensores do Bun destacam ferramentas integradas (gerenciador de pacotes, test runner, bundler, suporte a imagem e SQL) e desempenho como grandes vantagens sobre a proliferação de ferramentas do Node.
- Outros sugerem simplesmente usar pnpm/yarn com Node, ou Deno, para mais estabilidade e alinhamento com padrões.
Código gerado por IA e debate mais amplo sobre IA
- A reescrita é vista como um caso de teste importante para desenvolvimento assistido por LLM:
- Os apoiadores dizem que reescritas de uma linguagem para outra são um encaixe natural para LLMs, especialmente quando validadas por testes.
- Os céticos questionam a manutenção de longo prazo, o possível código “espaguete” e o custo econômico total quando a supervisão humana e o gasto com tokens são contabilizados.
- Alguns explicitamente esperam que a reescrita fracasse para furar o hype de que “IA vai substituir desenvolvedores”; outros argumentam que as pessoas estão se esforçando demais tanto para provar quanto para refutar o sucesso dos LLMs.