O suporte ao Bun agora será limitado e entrará em descontinuação
(github.com/yt-dlp)- Esta issue ainda está Open e, a partir da próxima versão do yt-dlp e/ou do
ejs, o escopo de suporte ao Bun será limitado a versões entre1.2.11e1.3.14, e o próprio suporte também passará a ser considerado em descontinuação - O yt-dlp continuará usando o Bun como runtime JavaScript compatível com
ejs, mas deixa reservada a possibilidade de remover completamente o suporte ao Bun caso o custo de manutenção aumente - A versão mínima suportada sobe de
1.0.31para1.2.11; considera-se que, ao compilar o pacoteejscom Bun anterior a1.2.0, o arquivo de lock doejsé ignorado, o que é visto como uma grande preocupação de segurança diante dos recentes ataques à cadeia de suprimentos do npm - O motivo para definir
1.2.11— e não1.2.0— como limite inferior é que, em versões do Bun anteriores à1.2.11, não é possível executar a suíte de testes doejs - O limite superior foi fixado em
1.3.14, com a justificativa de que essa foi a última release originalmente compilada a partir da base de código em Zig - Foi apontado que o Bun foi recentemente reescrito em Rust com uso do Claude, e que sua direção de desenvolvimento parece caminhar para algo “totalmente vibe-coded”, o que levanta preocupações sobre carga futura de manutenção e confiabilidade
- Em um comentário, alguém rebateu dizendo que o Deno também estaria sendo “vibe coded”, mas um mantenedor respondeu que há uma grande diferença entre usar Claude e depender completamente do Claude
- À pergunta se as versões de
1.3.4até1.3.14também não deveriam ser excluídas do suporte por possivelmente terem sido afetadas pelo “vibe coding” após a aquisição pela Anthropic, o mantenedor respondeu que vai analisar - Alguns usuários se opõem, argumentando que bloquear a execução das versões mais novas do Bun antes que problemas reais apareçam é uma limitação preventiva sem fundamento, e que deveria haver um aviso ou flag para ainda permitir a execução
- Outro comentário explica que é possível passar diretamente o caminho do binário do Bun em
--js-runtimes, então daria para continuar usando normalmente o Bun mais recente e apontar um Bun estático1.3.14apenas para o yt-dlp como solução alternativa - Como avisos relacionados, foram vinculadas a issue de fim de suporte ao Node v20·v21 e a issue que eleva a versão mínima suportada do Deno para
v2.3.0; também foi informado que o documento da wiki do EJS ainda não reflete esta mudança - Levando em conta os comentários vindos do Hacker News, um mantenedor deixou um comentário fixado pedindo que, antes de comentar, as pessoas pensem primeiro se realmente têm interesse na questão de usar Bun no yt-dlp
1 comentários
Comentários do Hacker News
Entendo a decisão. Se a maior parte do código não foi escrita pelo próprio mantenedor, deve ser difícil entender de verdade a base de código
Revisar toda a reescrita também é praticamente impossível. São exatamente 1 milhão de linhas de código https://github.com/oven-sh/bun/pull/30412
No fim, é mais ou menos o mesmo conteúdo escrito em outra sintaxe, então talvez isso apenas pareça feio aos olhos de desenvolvedores Rust. Os desenvolvedores do Bun provavelmente queriam código que parecesse mais familiar para eles
Ainda assim, acho que isso deveria ter sido chamado de 2.0. Assim, passaria menos essa sensação de correria. Já existem algumas regressões no 1.3.14, mas agora há tantos pequenos incêndios relacionados a Rust que parece que ninguém está dando muita atenção
O problema maior é que o Bun continua correndo atrás de recursos novos e chamativos sem finalizar as coisas até o fim. Os testes cobrem a maior parte do Vitest, mas não tudo; a maior parte do Jest, mas não tudo; a maior parte do pnpm, mas não tudo. Agora também tem recurso de imagens, então cobre a maior parte do sharp, mas não tudo. O servidor de desenvolvimento cobre a maior parte do Vite, mas de novo não tudo. Processos de longa duração são em grande parte parecidos com Node, mas há vazamentos de memória, e isso provavelmente foi uma motivação para a migração para Rust
Quando vi a postagem sobre as rotinas de imagem, isso me desanimou. Era mais um objeto brilhante, e, somado aos bugs de teste, acabei migrando completamente para Vitest
Não estou convencido de que essa reescrita em si seja uma boa ideia ou vá dar certo, mas a lógica contrária também é difícil de aceitar
Ninguém sabe o que aquelas mais de 1 milhão de linhas fazem. Ninguém lida com isso com entusiasmo. Recebem requisitos e tratam todo o resto como caixa-preta, exceto a superfície que precisam mexer
Aí surgem 14 implementações de serviços de fundo fazendo a mesma coisa, 8 dependências com o mesmo papel, 6 frameworks sobrepostos e uma incompatibilidade total de estilos e abordagens. E mesmo assim ninguém liga muito
Acho melhor do que puro “vibe coding”, mas, se até dá para aceitar isso em partes não importantes, em infraestrutura central que exige reflexão profunda isso é difícil de engolir
Isso não é discriminar alguém pela raça ou religião. Se você não quer uma grande superfície gerada por vibe coding, por que precisaria se justificar?
Isso entra na margem “artística” de decisão do desenvolvedor, e parece que esqueceram que software, por natureza, carrega opiniões
Se funciona, vai continuar funcionando. Eles só não querem dar suporte, manter e resolver issues disso
Se o Bun portado para Rust for melhor em todos os aspectos mensuráveis, passar em todos os testes, tiver desempenho igual ou melhor e ainda corrigir bugs existentes, por que importaria em que linguagem foi escrito ou como foi implementado? O ponto central é que a qualidade é maior
Se você não consegue confiar na versão Rust quando a equipe do Bun a lança e aprova, então também não faz sentido, logicamente, confiar na versão Zig de duas semanas atrás. Isso faz os desenvolvedores do yt-dlp parecerem tolos
Gosto muito de usar Bun, então é meio triste ver a direção mudar assim depois da aquisição pela Anthropic
Quero um bom Node com tudo incluso, mas não quero que seja feito com vibe coding
Não estou dizendo que apoio a fusão. Sou contra esse tipo de abordagem de engenharia estilo YOLO. Só que, desde o anúncio, não acompanhei as novidades e fiquei curioso sobre como essa transição está indo
Claro, engraçado no sentido terrivelmente triste
Essa decisão parece mais um julgamento político do que de engenharia. Você viu aumento de falhas de segmentação, falta de memória, vulnerabilidades de segurança ou bugs no Bun depois da reescrita em Rust?
Claro que não viu, porque essa reescrita nem entrou ainda. Parece uma decisão tomada porque a ideia de participação de IA causa má impressão
Ferramentas de engenharia não são escolhidas por sentimento, e sim por fazerem ou não o que você quer. Se o Bun passar a ter mais bugs e parecer um software pior, eu não usaria, mas esse julgamento seria baseado em dados. Jarred já fez muita coisa impressionante com o Bun, e não parece alguém que vá lançar uma reescrita que não atenda ao próprio padrão de qualidade, então vou observar
Se você acha que existe uma possibilidade razoável de aumento de falhas de segurança, experimentar isso nos usuários pode até ser visto como imprudente
A escolha responsável é algo mais próximo de “não vamos dar suporte imediato à execução do nosso software em uma nova versão do Bun cortada do main atual”
Ainda assim, é uma pena que pareça mais uma intenção de nunca mais suportar isso no futuro do que um plano de reavaliar versões futuras. Claro, os desenvolvedores do yt-dlp não devem nada a ninguém
Uma reescrita completa de 1 milhão de linhas é, na prática, um runtime novo com a mesma ABI de antes, e, para muitos consumidores downstream, isso não é algo confortável como dependência de produção
Mesmo que, por hipótese, o Bun tivesse sido todo reescrito manualmente por humanos, a situação seria a mesma. Acho esse tipo de decisão bem padrão e, pessoalmente, também acredito que a qualidade geral da reescrita com LLM do Bun provavelmente será boa, mas eu não apostaria meu produto nem minha empresa nisso. Mudanças arriscadas eu prefiro escolher no meu software, e não ser forçado a absorvê-las por causa de uma dependência indireta
Eu não vou ficar sentado esperando até os bugs explodirem e tudo começar a quebrar
Se for um projeto de alguém que escolhe ferramenta só olhando se “faz o que eu quero”, eu tiraria isso das minhas dependências
O momento mais fácil para escapar de uma ferramenta que pode virar um desastre ferroviário é antes de integrá-la
Isso é sobre a conversão para Rust, mas ela ainda não foi lançada
Falam em “problemas previsíveis de compatibilidade e segurança”, mas a versão Zig do Bun também trava bastante
Eu gostaria que o yt-dlp tivesse linkado uma justificativa mais detalhada para explicar por que existem problemas previsíveis de compatibilidade. Os dois projetos têm suítes de testes, então, em um mundo ideal, uma reescrita rápida deveria ser possível
Pode ser que não queiram acirrar ainda mais a situação, mas, se encontraram problemas concretos, eu gostaria de ver
O Bun.rs deveria ser uma 1.4 ou 2.0, e eu também gostaria que houvesse releases alfa/beta
Mas ele só foi tornado público há uma semana, e até agora quase não se vê dados reais de regressão. Parece mais uma reclamação do tipo “simplesmente não gostei”
Essa lógica me soa não muito diferente de dizer “o libfoo começou a ser desenvolvido em emacs em vez de vim, então não dá mais para confiar”
Claro, não é exatamente a mesma coisa, mas dá para entender por que causa essa sensação
A única verdade no software é se funciona ou não no meu caso de uso. Mesmo antes da IA, você nunca sabia se o autor tinha sido rigoroso ou se foi tentando aleatoriamente até dar certo
Em outras palavras, eu não julgava software investigando metodologia ou ferramentas usadas. Já usei muito software sem suíte de testes ou com testes ruins, e gente que gosta de segurança de memória usa ferramentas escritas em C, e vice-versa
Por isso, a lógica de “não vou usar porque não gostei do jeito como a IA foi usada” soa tão fraca quanto parar de usar algo porque não gostou do editor escolhido pelo autor
Se não fosse assim, nem existiriam conceitos como chocolate/café fair trade
Para os clientes que usam o produto, isso seria quase o mesmo que o mantenedor trocar de editor de texto, um detalhe irrelevante?
Mas não haveria tanta gente dizendo isso sobre LLM
O Bun feito por vibe coding pode acabar sendo tão bom quanto o Bun antigo ou até melhor, mas como saber isso agora?
E também não é verdade dizer que “não dava para saber se o software era feito com rigor e eu não julgava pela metodologia”. Algumas pessoas verificam diretamente se há um nível aceitável de rigor antes de adotar um projeto ou decidir continuar usando-o. Eu faço isso quando é algo importante
Muito mais gente usa sinais de reputação, que não são perfeitos, mas têm correlação e podem ser suficientes, além de serem muito mais fáceis do que uma revisão manual completa
Precisamos urgentemente de um novo termo para descrever como LLMs são usadas no trabalho de desenvolvimento. “Vibe coding” tem uma definição mais estrita, mas parece que ninguém se importa com isso
É realmente difícil acreditar que essa portabilidade para Rust tenha sido feita 100% no sentido original de “vibe”
Virou um lamaçal emocional, tanto para o lado positivo quanto para o negativo, e, quando “vibe coding” é usado como xingamento genérico para uso de LLM, fica difícil entender qual problema real está sendo apontado
Eu uso LLM para auxiliar no desenvolvimento e estou fazendo um trabalho melhor, mais rápido, em praticamente todos os critérios que um engenheiro consideraria importantes
https://x.com/karpathy/status/1886192184808149383
No caso específico dessa portabilidade, ela avançou tão rápido que parece claro que um humano não validou a correção da tradução. E também não está claro se haverá validação manual de verdade daqui para frente
Ainda assim, pelo critério de Dijkstra, a maioria dos projetos de software já fazia “vibe coding” muito antes da IA aparecer. No sentido de se entregar às vibrações e esquecer que correção existe
Garantir a correção de código complexo é difícil, mas isso vai deixando de ser opcional em uma era em que há 1 bilhão de hackers dentro dos datacenters
Adendo: “A porta Rust pré-lançamento do Bun tem 13.365 blocos unsafe”
https://news.ycombinator.com/item?id=48239790
Como é uma tecnologia muito nova, é difícil estudar, mas mesmo olhando com otimismo as evidências empíricas parecem mostrar algo como melhoria de cerca de 3% em alguns domínios
Escrever código raramente é o gargalo no nosso trabalho
Não sei por que tanta gente se sente tão pressionada por essa decisão. Se você é realmente um entusiasta de vibe coding, não poderia simplesmente criar por vibe coding um yt-dlp melhor, ou fazer um fork do atual e moldá-lo como quiser?
Diziam até que as pessoas fariam software pessoal descartável para qualquer tarefa com vibe coding
Então quem faz vibe coding não deveria ter motivo para reclamar de decisão nenhuma de software. Fazer por vibe coding um fork pessoal mais do seu gosto não deveria ser moleza? Não era essa a promessa do vibe coding?
Isso é aquela sensação equivocada de direito adquirido que as pessoas costumam ter em relação a projetos mantidos com o tempo e esforço de outros. Continua chocante essa postura de querer voluntariar livremente o tempo e o esforço alheios para ter o recurso que deseja
Quem faz o trabalho tem o direito de tomar as decisões, e, se não gostar, a pessoa pode fazer um fork. Esse ecossistema sempre funcionou assim
O yt-dlp continua sendo surpreendentemente fácil de mexer
Passo por isso até no trabalho, e é enlouquecedor que, quando o assunto é IA, divergências técnicas honestas pareçam não ser permitidas
Não sei bem como me sentir sobre a reescrita do Bun
Por um lado, o fato de a maior parte da base de código não ter sido revisada parece bem assustador
Por outro, pelo que ouvi, os testes passam com quase nenhuma regressão
Talvez seja por falta de experiência nessa área, mas eu não acho que confiaria a esse ponto nos testes a ponto de depender totalmente deles sem ler o código