Minhas reflexões sobre a reescrita do Bun em Rust
(andrewkelley.me)- Andrew Kelley, criador do Zig, interpreta a reescrita do Bun em Rust não como um caso de vitória ou derrota de recursos da linguagem, mas como um episódio que revelou o colapso da relação entre a Zig Software Foundation (ZSF) e a Bun/Oven
- No início, o Bun reconhecia o Zig como base de seus ganhos de desempenho e fazia doações anuais de US$ 60.000 para a ZSF, mas, depois de se tornar uma startup financiada por VC, cresceram as insatisfações em torno da operação da organização e da qualidade do código
- A ZSF se preocupava com implementações improvisadas, abuso de assertions no código-base do Bun e com o pouco tempo dedicado a corrigir bugs e dívida técnica em comparação com a velocidade de adição de recursos, além de considerar incômodo o fato de o Bun parecer um caso emblemático do Zig
- Kelley critica o texto sobre a migração do Bun para Rust por transformar a redução de bugs em um confronto entre guia de estilo vs. recursos da linguagem, e considera que o ponto central real é o tempo de engenharia investido na eliminação de bugs e no controle da qualidade do código
- A ZSF agradece pelas doações do Bun, mas, após a aquisição pela Anthropic, tanto as doações quanto a relação chegaram ao fim; a fundação vê de forma positiva o fato de a reescrita em Rust separar os interesses comerciais de Zig e Bun
A relação inicial entre Bun e Zig
- Jarred entrou na comunidade Zig há cerca de 5 anos, e Kelley o via como alguém com forte “energia de iniciante”, que tenta rápido e aprende muito
- À medida que o Bun passou a chamar atenção como toolchain JavaScript, mais interesse também começou a se voltar para o Zig
- Kelley acredita que Jarred poderia ter construído uma renda estável em São Francisco apenas com financiamento coletivo, mas entende que ele adotou uma mentalidade ao estilo Thiel Fellowship e uma abordagem típica do Vale do Silício, escolhendo o capital de risco
- O Bun inicial era favorável ao projeto Zig
- No site do Bun, o Zig era creditado pelos ganhos de desempenho
- Foi configurada uma doação mensal equivalente a US$ 60.000 por ano para a Zig Software Foundation
- Kelley também avalia que, mesmo no texto sobre a reescrita em Rust, o agradecimento ao projeto Zig parece sincero
As fissuras após virar uma startup financiada por VC
- Depois que o Bun se tornou uma startup financiada por VC, Jarred passou de um desenvolvedor que fazia código aberto crescer junto com a comunidade para alguém mais próximo de um operador de negócios
- As mensagens de contratação da Oven indicavam uma carga intensa de trabalho nos primeiros cerca de 9 meses e afirmavam que, se work-life balance significasse “ter muito tempo sem trabalhar”, então talvez aquilo não fosse adequado
- Kelley diz que, ao conversar com candidatos e funcionários da Oven, ouviu repetidamente mensagens negativas sobre o papel de Jarred como gestor
- Os problemas citados eram falta de comunicação, expectativas irreais, pouca empatia e falta de experiência
- Como resultado, membros da comunidade que queriam trabalhar com Zig passaram a evitar a Oven e o Bun
- Quanto mais Jarred se concentrava em produtividade e estratégia de saída para startup, mais ele se distanciava da visão de longo prazo de Kelley para o Zig
- Como exemplo, Jarred pediu prioridade para implementação de Language Server Protocol e integração com VSCode, mas Kelley tinha um plano maior em mente
Os problemas de qualidade do código do Bun na visão da ZSF
- Para Kelley, o problema central é a qualidade do código
- A equipe do Zig lê o código-fonte de projetos de usuários, verifica como mudanças na linguagem os afetam e testa quebras e regressões de desempenho causadas por alterações
- No código-base do Bun, aumentaram práticas de programação que preocupavam a ZSF
- Implementações improvisadas continuavam se acumulando
- Havia abuso de assertions
- Em comparação com a velocidade de adicionar recursos, havia pouco tempo para reflexão, remoção de bugs e redução de dívida técnica
- Kelley temia que essa forma de trabalhar no Bun pudesse se combinar com críticas à segurança de memória do Zig, e queria tomar distância social do projeto Zig em relação a isso
- A ZSF tentou conduzir o Bun para práticas de programação melhores, mas não conseguiu resultado
A aquisição pela Anthropic e a reescrita em Rust
- Dentro da ZSF, surgiu a avaliação de que o Bun estava mais próximo de um passivo líquido (net liability)
- Embora o Bun parecesse um caso emblemático do Zig, na prática ele se aproximava mais de um exemplo de “é assim que não se deve escrever código em Zig”
- Kelley sempre considerou frágil o plano de negócios do Bun de “vender alguma coisa de cloud” e via a possibilidade de que, se houvesse uma venda no futuro, o Zig também acabasse recebendo publicidade negativa de forma indireta
- Após a aquisição pela Anthropic, a ZSF sentiu alívio
- As doações foram silenciosamente interrompidas, e a ZSF já esperava por isso
- O lado do Bun não cancelou nem compareceu às reuniões mensais, e isso foi entendido como o fim da relação
- A ZSF suspeitou que a reescrita em Rust viria em poucos dias e torceu por isso
- Após a aquisição pela Anthropic, mesmo a ligação indireta de Claude ser escrito com Bun, e Bun com Zig, já gerava incômodo para a comunidade Zig
- Aumentaram as drive-by slop contributions
- Entraram usuários entusiastas de IA que colavam saídas de LLM em posts do fórum
- Kelley teme que o Zig passe a ser conhecido como uma linguagem de programação associada à IA
- Quando Jarred anunciou a reescrita em Rust, Kelley diz ter recebido isso muito bem e expressa a sensação de que agora “não é mais problema meu”
Contestação ao texto do Bun sobre a reescrita em Rust
- Kelley considera que o texto do Bun sobre a reescrita em Rust é bem escrito, mas aponta alguns problemas centrais
-
O ponto central da redução de bugs
- O texto do Bun constrói a ideia de que, para evitar bugs, seria preciso escolher entre guia de estilo e recursos da linguagem
- Para Kelley, o principal meio de eliminar bugs é investir recursos de engenharia para encontrá-los e removê-los
- Na visão dele, o TigerBeetle dedicou tempo para encontrar e eliminar bugs e manteve uma relação saudável com a ZSF, enquanto o Bun não fez nenhuma das duas coisas
-
A contradição sobre a suíte de testes
- Kelley entende que o texto do Bun usa a suficiência da suíte de testes como justificativa para poder distribuir 1 milhão de linhas de código não revisado
- Ele questiona então por que o código Zig tinha tantos bugs incômodos e se a suíte de testes não consegue capturar bugs no código Zig, mas consegue capturar bugs em 1 milhão de linhas de código não revisado
-
Desempenho e LTO
- O texto do Bun atribui ganhos de desempenho ao LTO, mas Kelley afirma que o Zig ofereceu suporte a LTO durante todo o período do Bun
- No passado, o Zig habilitou LTO por padrão, mas removeu isso da configuração padrão porque havia bugs demais no LLVM, os quais também afetam Rust
- Kelley considera bastante provável que a ZSF tenha recomendado ativar LTO e que o Bun não tenha dado ouvidos
-
fuzzing
- O texto do Bun sugere que houve fuzzing diligente do código Zig, mas Kelley afirma que, em uma ligação, a equipe do Bun disse que não fazia fuzzing de nada
-
Tamanho do binário e
comptime- O texto do Bun apresenta vários trabalhos de engenharia para reduzir o tamanho do binário como se fossem justificativa para a reescrita em Rust, mas Kelley entende que esses trabalhos não têm relação com a reescrita em si
- Eles se parecem mais com trabalhos de engenharia que deveriam ter sido feitos no código-base em Zig desde o início
- A ZSF alertou por anos sobre o abuso de
comptimeno Bun e até criou a função de relatório de tempo para permitir auditoria do uso decomptime/inlinee do tempo de compilação
-
Velocidade de compilação
- Kelley aponta que o texto do Bun não menciona a velocidade de compilação
- O projeto do compilador Zig tem cerca de 600.000 linhas, escala semelhante à do Bun antes da reescrita
- Nas medições de Kelley, uma compilação do zero com cache limpo leva 16 segundos, e, com compilação incremental ativada, cada edição posterior leva 90 ms
- Ele pergunta quais são as medições equivalentes do Bun após a reescrita em Rust
A conclusão de Kelley
- Para Kelley, o problema central não são os recursos da linguagem de programação, e sim o colapso da relação
- A ZSF agradece sinceramente pelas doações recebidas do Bun e usou esse dinheiro para a remuneração de contribuidores do Zig
- Kelley deixa claro que não pretende fazer uma crítica maliciosa a Jarred como pessoa
- Jarred tem gostos e objetivos de vida diferentes dos dele, mas, na visão de Kelley, conseguiu construir com sucesso a vida que queria
- Ele aceita que Jarred é feliz e bem-sucedido e afirma não ter má intenção
- Ainda assim, Kelley se diz satisfeito por os interesses comerciais da ZSF e do Bun não estarem mais entrelaçados
- Ele considera que, quando terminar o debate público sobre os prós e contras da reescrita em Rust como critério de escolha de linguagem, também terminará a interação entre os dois lados
2 comentários
Depois de ler o texto, fiquei sem vontade de usar tanto Zig quanto Bun.
Comentários do Hacker News
Aprendi muito lendo o código do Andrew e, como ele mesmo disse no texto original, o Bun não existiria sem Zig
Sobre a parte “o texto afirma que fizeram fuzzing no código em Zig, mas, durante a ligação, a equipe inteira do Bun disse que não faz fuzzing em nada. Isso parece uma distorção descarada”, existe um PR de integração do Fuzzilli: https://github.com/oven-sh/bun/pull/24826
Também há PRs já mesclados corrigindo problemas encontrados pelo Fuzzilli no código Zig do Bun: https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
Se buscar por “Fuzzilli”, aparecem mais PRs: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...
zig build test --fuzz, ou seja, o fuzzer embutido do Zig; é esse o tipo de ferramenta que está dentro do escopo deleNão idolatro nenhum dos dois; só estou curioso porque a conversa toda parece estar piorando em vez de caminhar para algo melhor
Receber downvote só por fazer uma pergunta de checagem de fatos é bastante revelador. Pode até ser uma resposta simples do tipo “até recentemente não usávamos fuzzer, então os dois estão certos”, mas estou perguntando justamente porque não sei
Este texto é algo pouco profissional e constrangedor para o Zig
Quase não sei nada sobre o Jarred, mas o texto dele que li ontem parecia grato ao Zig, e agora vejo que ele até doou uma quantia considerável para o Zig
O texto inteiro parece atacá-lo pública e pessoalmente por ter escolhido outro produto
Se o Andrew acha que esse texto vai ajudar a explicar o Zig, isso é estranho; na prática, só faz parecer infantil. Ou talvez ele só queira atacar o Jarred, não sei
Todo mundo agora tem que virar uma marca ambulante, medir cada palavra, andar em ovos e se esconder atrás de linguagem corporativa para parecer “profissional”?
O mundo precisa de mais franqueza, não menos, e as interações online parecem cada vez menos autênticas
O Zig, na prática, é quase um projeto de uma pessoa só, e essa pessoa está tomando decisões cada vez mais instáveis
Claro, o projeto é dele e ele tem esse direito, mas uma empresa valendo centenas de bilhões dificilmente vai querer assumir esse tipo de risco de supply chain
Do ponto de vista da Anthropic, faz mais sentido cortar isso pela raiz do que investir mais no ecossistema Zig quando ficou claro o risco de um not-so-BDFL passar dos limites
Já o Zig, considerando o nível de adoção e o tempo de desenvolvimento, tem uma cobertura de testes constrangedoramente baixa
A postura do Zig em relação à IA é completamente infantil. Há muito a ganhar, e mesmo assim não se avalia nenhuma possibilidade de uso
Uma coisa é tentar impedir spam de PRs; outra é amarrar as próprias mãos e não usar IA nem internamente nas áreas mais fáceis e de maior retorno
Também daria para usar IA para filtrar, no meio do spam de PRs, os candidatos a bugs reais, mas como não aceitam nenhuma ajuda, bugs de verdade acabam ficando sem correção por mais tempo do que precisariam
Infelizmente, há desenvolvedores de open source demais que se sentem confortáveis demais escrevendo assim, e esse é um dos motivos pelos quais deixei de contribuir com open source
Em qualquer ambiente de trabalho razoável, agir desse jeito renderia demissão ou, no mínimo, uma advertência
A frase “não é uma crítica pessoal ao Jarred” é bem forte para aparecer no fim de um texto que, em grande parte, parece uma crítica pessoal mal disfarçada
É o tipo de coisa como dizer que alguém tem energia de iniciante e embrulhar isso numa falsa positividade de “alguém que falha e aprende”, ou escrever que, segundo rumores, ele é chamado de “gerente fedorento”
Fica mais perto de “não estou dizendo que essa pessoa é ruim, mas vou escrever no blog que todo mundo concorda que ela é ruim”, e mesmo que seja verdade, parece de muito mau gosto
Eu também trabalho com gestores péssimos, mas não guardo ressentimento pessoal
“A rede de boatos era grande e saudável, cheia de uvas suculentas, e o suco de todas essas uvas carregava a mesma mensagem: Jarred era um gerente fedorento”
“Jarred já escrevia coisas lixo antes mesmo de usar LLMs”
É um texto estranhamente infantil. Eu até gosto de textos em que a pessoa fala sem passar pelo filtro corporativo, mas isso também mostra como ela pensa e age
Uma boa liderança, mesmo sem o filtro corporativo, ainda produz algo profissional, e este texto revela algo muito abaixo disso
Quando é seguro e não há dependentes, isso é completamente normal. É diferente de trabalho de gestão
Achei marcante a parte em que a ZSF respirou aliviada quando a aquisição pela Anthropic foi concluída. Quer dizer que, quando as doações foram silenciosamente interrompidas, a conta já estava pronta, e eles nem se surpreenderam quando as reuniões mensais deixaram de ser canceladas e simplesmente ninguém apareceu. A relação já tinha acabado
Já vi isso várias vezes. Quando um projeto ou organização é adquirido, o “bem” que eles faziam não termina com alarde; simplesmente some quando o patrocinador começa a ignorar em silêncio
Ainda bem que eles leram os sinais e se prepararam. É uma ótima lição para aprender sem precisar sofrer na pele, e projetos livres e de código aberto que dependem de um ou dois grandes doadores devem tomar cuidado
Acho que vamos ver isso muito mais no ecossistema de ferramentas para desenvolvedores daqui para frente
Em outros pontos desta thread há reações fortes ao tom do texto, mas este texto derrubou meu entusiasmo com Zig
O drama é divertido e a sinceridade do Andrew talvez seja até admirável, mas esse não é o tipo de profissionalismo necessário para um projeto sério
Mesmo que pareça entediante e sem inspiração, é esse tipo de estabilidade que eu quero de uma stack tecnológica e de quem a mantém
O Jarred pode até ter sido prejuízo líquido, mas o Bun era um projeto enorme que usava Zig, e perder esse projeto não é algo tão bom para Zig quanto o Andrew diz
Ele parece dar prioridade muito maior à pureza e à ideologia do que ao crescimento da linguagem. Para uma linguagem de programação séria, adoção e massa crítica também são fatores importantes
É parecido com dizer que o Linux não poderia ter virado um projeto sério por causa do tom dos e-mails do Linus
E nem foi algo escrito diretamente; foi num blog pessoal
O que importa não é a contribuição dele para a linguagem?
Por que adoção e massa crítica precisam ser necessariamente importantes? Qual o problema de fazer uma linguagem alinhada à pureza e à ideologia que a pessoa quer, mesmo abrindo mão de adoção mais ampla?
Por que tudo precisa ser otimizado para crescimento de usuários e reconhecimento?
Mesmo que eles finjam que sim
Este texto foi bem revigorante. Deve ter havido uma grande tentação de rebater a linguagem de PR do texto do Bun de forma mais polida, mas ele não fez isso
Ele poderia ter incluído fatos que fazem o Jarred parecer mal enquanto escondia cuidadosamente a própria opinião, por exemplo com algo como “ouvi dizer que as pessoas o chamam de gerente fedorento; não sou eu dizendo isso, são os outros”, mas foi simplesmente honesto, e eu gostei disso
Só que o conteúdo dessa personalidade e desses pensamentos é bem difícil de aceitar
Como a primeira e maior parte do texto foi dedicada a ataques pessoais especulativos, fica difícil dar credibilidade ao que o autor diz
Era uma boa oportunidade para organizar os pontos fortes do Zig. Por causa dos textos evangelizadores e inspiradores do mitchellh, recentemente eu estava com vontade de aprender Zig, mas este texto diminuiu essa vontade
Há bastante coisa sobre como o Andrew vê o Jarred e a forma como ele trabalha e conduz o trabalho, mas não está claro para mim o que exatamente seria ataque pessoal, ou o que é ou não especulativo
Ataques pessoais contra Jarred não parecem ajudar muito a defender o uso de Zig
Deveria ter se concentrado na linguagem; não deveria ter usado expressões como “gerente fedorento”
Sinceramente, ao ler esse texto, dá vontade de evitar Andrew tanto quanto Jarred
É algo que muita gente da comunidade também testemunhou nos últimos meses
Dizer “Jarred, em seu papel profissional, afastou muitas pessoas da nossa comunidade, e queremos manter distância” não é o mesmo que dizer “Jarred é uma pessoa ruim na vida privada”
Claro, neste meio, considerando o quanto VCs costumam deixar a vida pessoal fora do trabalho, isso pode acabar sendo entendido quase da mesma forma, mas isso não é problema do Andrew
Não estou defendendo o estilo de escrita dele. Ao falar para um público neurotípico mais amplo, talvez ele pudesse ter disfarçado um pouco mais sua neurodivergência
Ainda assim, o projeto é dele, a comunidade dele já conhece essa característica, e isso também é uma variável conhecida
Em vez de atribuir o subtexto secundário de que “Andrew está tentando assassinar o caráter de Jarred”, talvez ajude reler partindo da premissa de que Andrew está sendo completamente sincero
Também não é a primeira vez que vejo um texto dele que soa abertamente maldoso. Está além do que se poderia chamar educadamente de “direto”
“Ficar em silêncio não era uma opção?”
Ao contrário da afirmação de que “não há críticas pessoais a Jarred”, o texto inteiro pareceu uma crítica pessoal a Jarred
Mesmo que seja verdade, não é sensato publicar isso dessa forma. Se o objetivo era defender Zig, também daria para fazer isso de um jeito menos pessoal
Todo esse trabalho de reescrever o Bun de Zig para Rust parece um grande movimento de marketing
Se a Anthropic AI é realmente tão poderosa assim, por que não encarregá-la de corrigir bugs e redesenhar a base de código existente do Bun em Zig, num esforço mais ambicioso que evitasse não só os bugs atuais como também bugs parecidos no futuro?
Isso feriu os sentimentos da Anthropic
Dá para imaginar que a Anthropic poderia querer adquirir o Bun mesmo sem esse tipo de encenação
Algumas semanas depois, o Bun começou a reescrita em Rust. Não foi dito explicitamente, mas acho possível que os dois acontecimentos estejam relacionados
Não sei qual das duas opções é pior