O criador do Zig diz a verdade, mas a Anthropic está blefando

 (raymyers.org)
2 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Enquanto a Anthropic promove o fim da engenharia de software como valor futuro, há críticas de que a migração do Bun de Zig para Rust também foi usada em uma narrativa promocional de que a IA pode substituir a engenharia
  • O Bun citou bugs de memória como motivo da migração, mas a falta de comparação de alternativas, prós e contras, além de não divulgar custos como a compilação lenta do Rust, pode fazer a justificativa parecer retrospectiva
  • Havia também opções para operar o Zig de outra forma, e o TigerStyle da TigerBeetle mostra um caso de prevenção de use-after-free com alocação estática de memória e testes por simulação
  • A abordagem de portar arquivo por arquivo para unsafe Rust é razoável por reduzir riscos e permitir redesenhos futuros, mas há pouca coerência em aceitar uma conversão por IA na escala de um milhão de linhas e, ao mesmo tempo, problematizar algumas linhas de código de gerenciamento de ponteiros que humanos leriam
  • Como harnesses de agentes, o borrow checker do Rust, regras de legibilidade e revisão humana continuam necessários, a adoção de agentes de codificação e o descarte da engenharia de software não são a mesma escolha

O fim da engenharia de software promovido pela Anthropic

  • A Anthropic vem impulsionando ativamente a narrativa de que, depois da programação, a engenharia de software e até a maior parte do trabalho humano desaparecerão
  • A empresa levantou US$ 132 bilhões em investimentos e se aproxima de um IPO com valuation acima de US$ 1 trilhão, mas, em uma situação em que não consegue demonstrar lucratividade, precisa vender uma influência futura hipotética
  • Por causa desses interesses, a Anthropic deve ser vista como uma narradora não confiável (unreliable narrator); importam não só a veracidade da mensagem, mas também seu efeito sobre o julgamento de executivos, líderes mundiais e gestores de fundos de previdência
  • A narrativa de IA afeta decisões de arquitetura, produto e alocação de pessoal e dificulta avaliações frias em meio ao medo de demissões, aos alertas de ficar para trás e ao Doom Trolling
  • Ao avaliar IA na área de software, é necessária uma análise cética que considere os interesses e objetivos promocionais da Anthropic

A migração do Bun de Zig para Rust e a explicação tardia

  • A Anthropic/Bun só explicou a decisão de migrar o Bun, escrito em Zig, para Rust dois meses depois de ela ter sido mesclada à branch principal
    • Em um grande projeto de infraestrutura, o mais comum seria explicar a direção antecipadamente
    • Enquanto a explicação demorava, títulos como Anthropic’s Bun Rust rewrite merged at speed of AI espalharam a impressão de que a IA havia concluído rapidamente a reescrita
  • Andrew Kelley, criador do Zig, publicou uma contestação e, em tom incomumente direto, criticou a tecnologia e a operação organizacional do Bun
    • Há um risco reputacional de abrir precedente para que o líder de uma linguagem anterior ataque até falhas pessoais só porque um projeto trocou de linguagem
    • Alguns chamaram isso de “meltdown”, mas também há espaço para ver como uma intervenção pública sobre problemas que precisavam ser apontados

Critérios para julgar uma crítica direta

  • A fala correta (right speech) no budismo considera que toda declaração deve satisfazer cinco critérios
    • É verdadeira?
    • É útil?
    • É oportuna?
    • É gentil?
    • Parte da gentileza?
  • A resposta de Andrew Kelley se enquadra em uma fala verdadeira, mas pouco gentil, e a questão é se havia necessidade de apontar publicamente o problema mesmo fugindo da cortesia habitual

Relação entre Bun, Zig e as políticas de contribuição por IA

  • Bun é um runtime de TypeScript comparado a um NodeJS mais rápido, e Zig é uma linguagem de programação de sistemas comparada a um C moderno
  • Até recentemente, o Bun era escrito em Zig e era uma das maiores bases de código em Zig
  • As políticas de contribuição por IA dos dois projetos são diametralmente opostas
  • Depois que a Anthropic adquiriu o Bun, o fundador Jarred Sumner conduziu um experimento em larga escala com agentes para migrar o código Zig para unsafe Rust, e o resultado foi mesclado alguns dias depois, tornando-se a versão oficial
  • Entre as partes envolvidas, não parece haver ninguém exigindo que o Bun continue em Zig; a controvérsia se concentra menos na migração em si e mais em seus motivos e na forma de promovê-la
  • Uma migração de linguagem em larga escala usando agentes é um experimento técnico que vale tentar novamente nas circunstâncias adequadas

Três interpretações sobre a mesma decisão

  • Para desenvolvedores que tentam escolher entre Zig e Rust, o fato de um dos maiores usuários de Zig ter revertido sua decisão é um dado importante para o julgamento
  • A interpretação da Anthropic/Bun é que todas as abordagens razoáveis foram tentadas, mas, com Zig, era difícil lidar com bugs de memória
  • Segundo a interpretação de Andrew Kelley, a base de código virou uma bagunça por causa de decisões de engenharia do Bun, como delegar demais a escrita e a revisão de código a agentes de IA
  • Uma possibilidade mais comum é que havia vários caminhos para resolver problemas reais de memória, mas a liderança achou mais fácil escolher uma reescrita em Rust
    • Isso permitia promover as capacidades do novo modelo Fable
    • A Anthropic já usava Rust
    • O projeto Zig se opõe publicamente ao uso de produtos da Anthropic
  • A migração para Rust pode ser racional do ponto de vista de negócios, mas a divulgação se concentrou na ideia de que a IA é poderosa o suficiente para realizar a reescrita
    • O fato de a IA não ter detectado preventivamente use-after-free entra em conflito com essa narrativa
  • O exagero pelo megafone da Anthropic força uma comparação direta entre os julgamentos de Jarred Sumner e Andrew Kelley e pode, sem intenção, afetar também a reputação do Zig

Por que a credibilidade pessoal entrou no debate técnico

  • Antes de tudo, o alvo de responsabilização deve ser a Anthropic, que usa este caso na narrativa de IA, mais do que o fundador individual do Bun
  • Como a Anthropic usa a credibilidade de Jarred Sumner para reforçar sua própria mensagem, responder a isso inevitavelmente exige avaliar também seus julgamentos e ações
  • Seria preferível discutir apenas os pontos técnicos, mas, quando a mensagem da Anthropic depende mais de espetáculo e divulgação do que de comparação técnica, a credibilidade pessoal acaba entrando no debate
  • Se apenas organizar o que a pessoa disse e fez publicamente parece difamação, esse próprio comportamento talvez seja parte do problema

Crunch permanente e o ambiente organizacional do Bun

  • O anúncio de vagas do Bun em 2022 alertava que os primeiros nove meses seriam muito duros e que a vaga não seria adequada para quem valoriza um equilíbrio entre trabalho e vida pessoal com muito tempo sem trabalhar
  • O modo crunch permanente faz mal tanto à saúde quanto à produtividade, algo confirmado repetidamente também por pesquisas empíricas sobre trabalho do conhecimento
  • Deve-se escolher gestores que protejam a possibilidade de os integrantes dormirem à noite, não gestores que se gabam de trabalhar 90 horas por semana
  • A avaliação que Andrew Kelley diz ter ouvido de pessoas ligadas à equipe do Bun se resume a falta de comunicação, expectativas irrealistas, baixa empatia e pouca experiência, mas há a limitação de ser um relato de terceiros
  • Ainda assim, essa avaliação também é coerente com o ambiente de trabalho extremo divulgado no anúncio de vagas
  • Mesmo em ambientes de trabalho ruins, tecnologias excelentes podem surgir, e o próprio Bun é uma ferramenta utilizável e interessante
  • A avaliação de que o código tinha muitos bugs e era difícil de manter não é apenas uma crítica externa; também é o estado que o próprio Bun apresentou como base para a migração para Rust

Valor prático da abordagem de port para unsafe Rust

  • Os detalhes técnicos do processo de transição têm valor de reutilização em outros projetos de modernização
  • O Bun não foi redesenhado do zero em Rust seguro; ele fez um port arquivo por arquivo para unsafe Rust
    • Manteve a estrutura existente, reduzindo o risco inicial da transição
    • Criou uma base para melhorar a segurança e fazer redesenhos posteriormente
  • A automação baseada em IA pode tornar mais fácil reverter escolhas de linguagem do que no passado, mas a reescrita automática ainda envolve prós, contras e diferenças semânticas
  • Também é possível combinar várias técnicas de reescrita e reforçá-las com métodos formais (Formal Methods)
  • O TRACTOR, da DARPA, é um programa de pesquisa para levar todo código C para Rust, e o relatório de avaliação publicado trata do estado atual das tecnologias de conversão automática
  • Mesmo que agentes ofereçam mais opções para código legado, ainda será preciso julgamento e comunicação para definir objetivos de modernização

Um documento de decisão técnica com muitas lacunas

  • Para explicar uma decisão técnica, são necessários pelo menos três elementos
    • Qual é a motivação
    • Quais alternativas foram avaliadas
    • Quais são os prós e contras de cada alternativa
  • O documento em que Richard Feldman resume por que levou o compilador Roc de Rust para Zig é um caso comparativo que contém os três elementos
  • A explicação do Bun apresentou a motivação dos bugs de memória, mas tratou apenas de parte das alternativas avaliadas, e a comparação de prós e contras praticamente está ausente
  • Em especial, omitir os prós e contras pode fazer parecer uma justificativa a posteriori, em que a resposta já foi definida desde o início e depois se adicionam os argumentos
  • Não se pode descartar a possibilidade de haver outros motivos não divulgados; para aumentar a credibilidade da decisão, também seria preciso expor os custos desfavoráveis

Uma comparação que lista apenas as vantagens do Rust

  • A seção “Bun is better in Rust” trata apenas dos benefícios da migração para Rust e quase não apresenta custos
  • Grandes bases de código em Rust geralmente pagam, em troca de segurança, o custo de tempos de compilação mais lentos
  • No passado, o Bun considerava importante a velocidade de compilação e tentou fazer um fork do compilador Zig para obter uma melhoria de 4x
  • Se o port para Rust aumentou o tempo de build dos contribuidores, divulgar isso e explicar por que a segurança é mais importante que esse custo aumentaria a credibilidade da decisão
  • Outras melhorias feitas depois da transição podem ter sido misturadas à lista de vantagens da reescrita em Rust, exagerando o efeito direto da mudança de linguagem

Alternativas de guia de estilo não avaliadas

  • No Bun, bugs de memória não eram a única causa de defeitos, mas, segundo uma contagem pessoal, eram frequentes a ponto de exigir 4 commits de correção por semana
  • Cada bug de memória significa que alguma convenção sobre como objetos são criados, possuídos e liberados foi quebrada em algum ponto; portanto, seria possível começar avaliando formas de definir com clareza o comportamento esperado em cada situação
  • O gerenciamento manual de memória amplia o escopo das convenções, mas diretrizes eficazes de uso são necessárias independentemente da linguagem, e o Rust também tem um guia de estilo de API

  • A alternativa mostrada pelo TigerBeetle

    • Outra base de código representativa em Zig, o banco de dados de transações financeiras TigerBeetle, não sofre com bugs de memória e parece ser um dos bancos de dados mais confiáveis
    • Ele usa o TigerStyle e testes por simulação como base de confiabilidade
    • O TigerStyle não é apenas um formato de código, mas uma filosofia de engenharia que reúne design, memória e testes
    • Toda a memória é alocada estaticamente na inicialização
    • Depois da inicialização, alocação dinâmica ou realocação após liberação não são permitidas
    • Isso bloqueia use-after-free, evitando variações de desempenho difíceis de prever
    • Ao considerar, na fase de design, os padrões possíveis de uso de memória, ele induz estruturas mais simples, rápidas e fáceis de raciocinar e manter
    • Nem toda aplicação consegue adotar esse método exatamente como ele é, mas ele mostra que a política de memória está ligada às decisões gerais de design

  • Lacunas restantes na explicação do Bun

    • O Bun menciona o TigerStyle e o guia de estilo C++ de 31 mil palavras do Google e, em seguida, resume que guias de estilo são difíceis de impor e tradicionalmente dependem de code review, linters e analisadores estáticos
    • Porém, ele não trata de qual guia de estilo o Bun realmente usava, por que ele falhou e como foi melhorado ao longo de 4 anos
    • Se problemas de memória persistiram em um projeto grande, é importante saber se a alternativa de usar a linguagem atual de outra forma foi testada seriamente, mas faltam evidências que sustentem isso
    • Um modo de operação em que uma pessoa mantém todo o contexto na cabeça e não faz reuniões dificulta criar convenções explícitas e um design compartilhado

A contradição entre revisão por agentes e guias de estilo

  • Embora o Bun veja guias de estilo como difíceis de impor, ele afirma que escreveu um PORTING.md para a migração e que agentes revisaram todo o código reescrito seguindo diretrizes rigorosas
  • O próprio PORTING.md é um guia de estilo especializado no escopo da transição; portanto, se a revisão por agentes funcionou, o problema de impor diretrizes também já teria sido resolvido
  • Em condições adequadas, a revisão por agentes pode funcionar, mas pressupõe regras e um método de revisão suficientemente bem projetados
  • O mesmo esforço mental poderia ter sido investido no redesenho do código Zig e no fortalecimento das convenções, mas o Bun escolheu a reescrita em vez da rearquitetura
  • Por vários motivos não divulgados, a reescrita pode ter sido a escolha correta, mas a explicação atual não oferece comparação suficiente com as alternativas

Uma reescrita de um milhão de linhas e três linhas de código de ponteiro

  • O Bun considera que, para expor expectativas de ownership no nível de tipos em Zig, seria necessário adicionar código como SharedPtr(TCPSocket) e deref(), o que seria menos conveniente do que o uso atual de ponteiros
  • Nesse exemplo, cerca de três linhas de código são acrescentadas para deixar clara a passagem de ponteiros nas fronteiras de interface
  • Aceitar um PR de um milhão de linhas gerado por IA e difícil de revisar, enquanto rejeita algumas linhas que deixam claro o ownership de ponteiros por problema de legibilidade, é uma postura pouco consistente
  • Jarred Sumner já afirmou que passou meses sem digitar código diretamente
  • Se o código não é para humanos, o argumento de que o wrapper SharedPtr é visualmente incômodo fica mais fraco; se é para humanos, legibilidade, revisabilidade e manutenibilidade precisam continuar sendo consideradas
  • Empresas de IA relutam em admitir que legibilidade de código ainda é importante, mas negar isso pode combinar com a narrativa de que a engenharia de software acabou, embora entre em choque com a realidade da manutenção
  • Também há benchmarks indicando que agentes de programação podem, por padrão, piorar a manutenibilidade

O que o mesmo caso revela: “só IA não basta”

  • A reescrita em larga escala do Bun por agentes não serviu apenas como melhoria técnica, mas também cumpriu uma função de negócios ao promover a mensagem da Anthropic de que “IA é suficiente”
  • No entanto, o mesmo caso também pode ser interpretado no sentido oposto
  • Sob a premissa de que até os problemas criados por agentes podem ser resolvidos com ainda mais agentes, está se espalhando a prática de comprar tokens em vez de ferramentas melhores e anexar SKILL.md em vez de aprender tecnologia
  • Chamar sessões paralelas de agentes de Team, em vez de entender a psicologia das equipes de software, confunde organizações humanas com sessões de execução automática

Adotar agentes de codificação e descartar a engenharia são coisas distintas

  • A campanha da Anthropic sobre o fim da engenharia de software pode ter efeito contrário tanto para quem cria ferramentas de IA quanto para quem as usa
  • Mesmo ao adotar agentes de codificação, não é necessário tomar como modelo ideal uma Dark Software Factory em que as pessoas não entendem o código
  • O objetivo é criar o que as pessoas querem e fazer com que funcione corretamente; a bolha de IA pode pressionar para criar, com baixa qualidade, coisas que elas não querem
  • É preciso usar IA em uma direção que não abra mão de julgamento, aprendizado, comunicação, legibilidade e manutenibilidade

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões do Hacker News

  • Este texto tem muita coisa boa, mas me lembra projetos gerados por IA que são abandonados em poucos meses. O valor de um projeto está em quanto ele foi validado na prática, mais do que na quantidade de código gerado, e código existente maduro é melhor do que uma nova reescrita
    A base de código Zig existente já foi validada, mas a reescrita em Rust tem validação próxima de zero além de passar nos testes; se foi uma tradução literal arquivo por arquivo usando unsafe Rust, nem fica claro em que ela é melhor que o Zig de partida. Só passará a fazer sentido depois de ser migrada para Rust seguro e validada em ambiente de produção e por muitos usuários
    Na prática, o Bun foi bifurcado, mas tanto faz se a versão em Zig ou a versão em Rust sobreviver; também não há motivo para encarar isso como um problema de adequação do Zig

    • Projetos de IA são abandonados porque são gerados no improviso. Custos irrecuperáveis podem até ser uma vantagem por fazerem a pessoa aguentar adversidades e períodos de estagnação, mas não se cria apego por algo feito apenas com uma ideia momentânea e um prompt no Claude
      Mesmo eu, um programador comum, tenho dezenas de ideias legais todos os dias, mas pouquíssimas sobrevivem a uma análise, e alguns dias depois até essas parecem não valer o esforço. Ideias sempre foram baratas e agora até provas de conceito ficaram baratas, então não me interesso por um Show HN no qual a pessoa não investiu nem um mês
    • Para chegar a um Rust seguro com validação prática significativa, é preciso começar em algum lugar; então a decisão foi primeiro fazer uma tradução literal e depois melhorá-la gradualmente
      O pessoal do Zig parece preocupado que Zig seja uma linguagem sem futuro desde o início, já que ela não tem vantagens suficientes sobre C para ser usada seriamente e até seu projeto mais representativo a abandonou. Ao pesquisar segfault no rastreador de issues do Zig, dá para entender por que se duvida de sua utilidade futura diante de alternativas como Rust
    • Ao contrário do Zig, agora há um limite unsafe claro e de escopo restrito, e isso é melhor porque pode ser corrigido ponto a ponto
    • A introdução do texto é cínica demais. Pelos conhecidos que tenho na Anthropic e na OpenAI, eles realmente acreditam que, em um futuro próximo, agentes vão assumir a maior parte da programação e eles próprios perderão seus empregos
      Não se trata de controlar a mensagem para dar lição no campo anti-IA
    • Não dá para afirmar que projetos gerados por IA são abandonados rapidamente por falta de validação prática. Projetos pessoais em geral também costumam ser abandonados depois de algum tempo, e, como agora é possível escrever código muito mais rápido, talvez a pessoa chegue mais cedo ao ponto de retorno marginal decrescente em utilidade pessoal, aprendizado e diversão

  • O problema maior não é o fato de Andrew ter sido direto, mas a postura dupla de o texto ser claramente um ataque pessoal e, ao mesmo tempo, alegar que não é
    Depois de ler esse texto, perdi a vontade de construir algo em Zig. Qualquer decisão técnica que eu tome pode levar o ditador benevolente vitalício (BDFL) do Zig a escrever algo assim, e é difícil imaginar a liderança de outras comunidades, como Python ou Rust, agindo desse modo

    • O pior é que há sinais de que essa postura está se espalhando pela comunidade Zig. Mesmo que ainda não seja a maioria, se as pessoas gentis forem embora para comunidades mais acolhedoras, a proporção desse tipo de atitude no grupo restante aumenta
    • Quero defender Andrew dizendo que ele se importa sinceramente em fazer a coisa certa e por isso tem opiniões fortes, mas, visto de longe, ele é uma pessoa mais paciente e inclusiva do que parece
      Alguém pode achar que Andrew atacou o Bun, e eu posso ver as reações contra Andrew como ataques pessoais. Se deixarmos os preconceitos de lado, deveríamos concluir que ambos os lados erraram ou que nenhum dos lados errou, e precisamos estar cientes de que, ao julgar uma situação de longe, os preconceitos pessoais pesam demais
    • Tudo bem, desde que a pessoa não saia escrevendo um texto potencialmente enganoso que faça o Zig parecer ruim e não falte sem avisar a uma reunião marcada com a Zig Foundation
    • O texto de Andrew foi revisado várias vezes, então ler a revisão mais recente talvez alivie as preocupações: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
    • Rust, por design, não tem BDFL, e pelo que me lembro Python também se afastou desse modelo. Contribuidores individuais podem ficar irritados e escrever textos agressivos, mas não há uma única pessoa que represente a linguagem como acontece com Zig

  • Quero ficar do lado de Andrew. Tendo acompanhado o trabalho de Sumner por anos, as críticas de Kelley, embora pouco gentis, são em grande parte verdadeiras; mesmo que o resultado seja útil e impressionante, do começo ao fim isso esteve mais para exercício de influência em autopromoção
    Eu também faço desenvolvimento baseado em agentes 8 horas por dia e venho recomendando ao meu time usar Rust e Deno em vez de Node, mas essa reescrita foi mal justificada e parece uma extensão da longa campanha de relações públicas que Dario e companhia conseguiram emplacar. Se a formulação fosse mais elegante, teria sido bem recebida, mas valorizo o fato de ele ter apresentado pensamentos sinceros em vez de um texto escrito por uma equipe de PR

    • A lição deste episódio é que, antes de publicar uma resposta exaltada, é preciso deixá-la descansar por 1 ou 2 dias e mostrá-la a amigos próximos. Teria sido melhor Andrew publicar já na primeira revisão algo parecido com a conclusão que ele corrigiu depois
    • A justificativa prévia para a reescrita foi fraca, mas dava para entender por que Jarred estava frustrado mesmo sem exemplos
      A explicação de que a interação com o coletor de lixo do JavaScript cria dificuldades específicas para o Bun foi útil, mas Andrew não tratou disso de forma alguma. A explicação de que o novo código foi validado pela suíte de testes existente também esclareceu o mal-entendido de que até os testes teriam sido traduzidos por vibe coding e, portanto, não seriam confiáveis. O fato de testes não pegarem todos os bugs vale para qualquer software, inclusive Zig
      No fim, a coisa se espalhou porque ao choque entre a visão de que linguagens sem segurança de memória geram enormes custos de defeitos e a resposta “fique melhor e não escreva bugs” se somaram a discussão sobre IA, o envolvimento da Anthropic e o estilo à la Linus de Andrew
    • A própria mentalidade de achar que se deve justificar uma reescrita para alguém fora da empresa é estranha
    • Em assuntos técnicos, prefiro uma postura à la Linus de dizer as coisas como elas são a frases de relações públicas; deixe a linguagem promocional para clientes não técnicos

  • Fico em dúvida se leram o texto da Anthropic e o de Andrew Kelley da mesma forma. A Anthropic não é uma empresa que vende linguagem de programação, e o texto sobre a reescrita do Bun em Rust trazia muitos detalhes técnicos mostrando como o produto melhorou para o usuário final
    Já a resposta do lado do Zig parece mais uma coluna mordaz cheia de ataques pessoais. Eu uso Codex e não tenho nenhum interesse em Zig nem em Rust, então observo de fora

    • A Anthropic claramente também tem interesse no mercado de linguagens de programação. Se a IA facilita reescritas para uma linguagem específica, os casos de sucesso associam essa linguagem à empresa de IA; e o sucesso do Rust como uma linguagem fácil de escrever com IA também beneficia a Anthropic
      Além disso, ao divulgar uma reescrita bem-sucedida, muitas vezes se escondem elementos desfavoráveis à narrativa, como o quanto o código antigo era ruim, e desta vez também faltaram aspectos importantes
      O texto de Andrew Kelley (https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) trata dos baixos padrões de engenharia de Jarred, de relações externas ruins, como faltar sem avisar a reuniões com a Zig Foundation, dos danos causados ao retratar o Zig como uma má escolha durante a transição para Rust, e da consequente irritação da ZSF
      Olhando superficialmente, é compreensível se preocupar que o criador de uma linguagem esteja atacando um ex-usuário, mas Kelley explicou por que essa impressão, que eu também tive ao ler apenas o texto do Bun, era injusta. Alguns ataques pessoais são claros, e a última seção acrescentada depois também trata disso
    • Imagine se, quando um estúdio migrasse de Unity para Unreal, a Unity publicasse um texto atacando a qualidade do código existente e o ambiente de trabalho; visto assim, é estranho o próprio Zig ter respondido
    • Este é um velho choque entre artesanato e industrialismo. Andrew pertence a uma tradição que deseja que todo desenvolvedor seja um artesão orgulhoso
      Java, JavaScript, Python e C# dominaram a indústria centrada em C++ ao oferecer mecanismos de segurança que permitem até a desenvolvedores não perfeccionistas trabalhar sem grandes acidentes. As vantagens de desempenho de C e C++ eram grandes, mas exigiam bastante habilidade em um ambiente cada vez mais hostil
      Rust e Swift ofereceram previsibilidade de desempenho maior do que linguagens com garbage collection, com segurança semelhante ou até superior, e as ideias do Rust levaram a uma explosão de novas linguagens nesse espaço. Ainda assim, muitas delas estão mais próximas do artesanato do que do Rust, que nasceu de necessidades industriais
      Usando uma analogia com veículos, Java, JavaScript e afins são carros comuns com segurança; C/C++ são motos de duas rodas; Rust é um carro de rali rápido, mas que protege os ocupantes; Zig se parece mais com um quadriciclo ou um kart de rodas expostas. Pode até não derrapar facilmente, mas, se capotar, é muito perigoso
      Artesãos que ignoram restrições de tempo e custo acham que basta ter desenvolvedores cuidadosos, mas, no ambiente industrial, mesmo que seja possível escrever bom código, 90% do trabalho acontece sob restrições, então é difícil confiar no meu código ou no dos outros. Zig tem muitas qualidades, mas desde o início foi uma linguagem para pessoas que preferem liberdade de hackear à segurança
    • As melhorias em tamanho de binário e velocidade não têm muita relação com a reescrita em Rust em si, e provavelmente também seriam possíveis com esforço semelhante na base de código em Zig. Houve um aspecto de trabalho adicional para fazer esses números parecerem bons ao promover a reescrita
      A segurança de memória também poderia ter sido obtida de modo semelhante se, em vez de IA, testes e fuzzing de nível mais alto, a equipe do Zig tivesse usado o fuzzer integrado com permissões. Ainda assim, para um projeto como o Bun, o Rust mais maduro pode ser uma boa escolha
      A perspectiva de Andrew foi essencial para entender o que aconteceu. Algumas expressões poderiam ter sido mais suaves, mas, se a má gestão foi a causa direta da deterioração da relação e de resultados de engenharia ruins, explicitar isso não é ataque pessoal, e sim contexto necessário
    • É míope dizer que um produto que aumenta a produtividade de programadores escrevendo código por eles não tem relação com o mercado de linguagens só porque não vende uma linguagem própria
      Especialmente porque a liderança do Zig detesta publicamente vibe coding e criticou a indústria, e o projeto vem recusando pedidos de contribuição feitos com esse produto

  • O que falta de fato nessa discussão é substância técnica. Não me interesso pela migração do Bun para Rust, pelo texto agressivo de Andrew nem pela Anthropic vendendo pás na corrida do ouro; quero ver conteúdo técnico concreto
    Os motivos apresentados por Jarred para a transição para Rust parecem válidos, ainda que com fundamentos um pouco fracos, mas Andrew não rebateu por que aquilo não é um problema real nem como resolveria da forma canônica em Zig. Gostaria especialmente que os argumentos fossem analisados com base no código Zig real do Bun

    • Considerando apenas os fatos apresentados pelo lado do Bun, a reescrita tem pouca justificativa técnica, e isso não surpreende, já que reescritas são má engenharia na maioria dos casos
      O Bun foi iniciado por alguém com pouca experiência em Zig, apesar de um escopo e uma complexidade enormes, e desde o começo já era um projeto de reescrita de código de outra linguagem. Se o transpilador de JavaScript e TypeScript do esbuild foi portado linha por linha de Go para Zig e, em poucos anos, toda a base de código foi descartada e reescrita em outra linguagem, fico me perguntando o que mais há a discutir
    • O ponto de Andrew é que o código do Bun já era ruim desde o início, e o texto pode ser lido como uma insinuação de que Jarred é uma pessoa tóxica e que nem vale a pena participar dessa discussão
    • O Bun quer se mover rápido e quebrar coisas, enquanto o Zig força um movimento lento e cuidadoso
      O Bun quer lançar recursos como uma linguagem de shell e clientes SQLite/PostgreSQL o mais rápido possível, então não quer se preocupar diretamente com gerenciamento de memória. O Zig faz você lidar diretamente com gerenciamento de memória e tempos de vida, e evita de propósito adicionar recursos como Drop; já o Rust se encaixa melhor justamente por causa de Drop
      Assim como não se cria um banco de dados SQL em Python, Zig não é a ferramenta certa para o Bun, e isso é mais uma diferença na forma como Jarred quer desenvolver o projeto rapidamente do que algo a ser resolvido de forma canônica em Zig
    • O texto original aborda essa questão diretamente, mas selecionou quase só os aspectos positivos. Por exemplo, diz que até reescreveram o compilador Zig para melhorar o tempo de build, então é curioso que não tenham tratado de forma alguma do tempo de build do Rust, que geralmente é muito mais lento
    • Quem vende pás na corrida do ouro são as empresas que constroem data centers e energia; os tokens são o ouro

  • Concordo com parte das opiniões de Kelley, mas o problema é o tom
    Se o Bun tivesse sido reescrito de Rust para Zig, é pouco provável que um membro do core team do Rust escrevesse um texto com ataques pessoais contra Sumner e alegasse que não era um ataque. Assim como Kelley tem liberdade para escrever o texto que quiser, as pessoas também têm liberdade para reagir à imagem pública do Zig criada pelo BDFL de uma linguagem em crescimento

  • O texto do Bun sobre a migração para Rust deixou de fora comparações concretas entre alternativas e números de impacto, e tratou o resultado de forma enviesada, então não pareceu um post de blog de engenharia
    Parece que as pessoas se interessaram mais pelo uso de agentes do que pelos fundamentos técnicos da portabilidade, e tecnicamente foi muito decepcionante

    • Fico me perguntando se lemos o mesmo texto. Ele não tratava de uma linha específica de código, mas trazia repetidamente detalhes profundos de arquitetura, fundamentos sobre segurança de memória e bugs, e padrões de codificação com agentes em larga escala

  • Não se deve subestimar o tamanho da influência do marketing sobre a diretoria e os executivos, especialmente o quanto pessoas que chegam a cargos como CEO podem ser movidas por emoções triviais
    Só o fato de ser uma oportunidade de promover o novo modelo Fable e de Zig se opor publicamente ao uso de produtos da Anthropic já pode ter feito com que a reescrita do Bun em Rust estivesse praticamente decidida

    • Não entendo por que achar que houve intervenção da direção de qualquer forma. É muito mais plausível que Jarred tenha feito o que ele próprio queria fazer, e ele mesmo vem dizendo isso

  • Não entendo por que, em um debate sobre troca de linguagem, estão entrando até em expectativas de jornada de trabalho. Mesmo que ele seja um péssimo gestor, parece uma tentativa forçada de procurar material negativo
    Também é significativo que o lado do Zig quase não se concentre nos méritos técnicos da reescrita em si. A Anthropic apresentou várias melhorias, mas é difícil encontrar sequer uma tentativa de refutá-las
    Se eu reescrevesse meu projeto com um grande modelo de linguagem e o resultado mostrasse melhorias sem desvantagens, eu ficaria bastante preocupado e reagiria; aqui, porém, estão discutindo jornada de trabalho sem relação com o ponto

  • Há um conflito de interesses evidente entre um projeto pertencente à Anthropic e a liderança de uma comunidade de linguagem que hostiliza publicamente código gerado por IA
    Andrew Kelley teria feito melhor em dizer apenas isso e parar por aí; avaliações sobre a energia e a motivação do fundador do Bun acrescentam muito pouco

    • É difícil haver acordo entre os dois lados, os que apoiam ou se opõem absolutamente à IA. A maior parte dos argumentos técnicos e ataques são racionalizações posteriores; o contexto e os objetivos apenas diferem de uma organização para outra
      Kelley também sabia disso, mas parece não ter resistido à tentação de turvar o ponto central. O texto agressivo ([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) passou do ponto, mas o apêndice sobre seguir em frente é saudável. Acho que um BDFL é melhor sendo um pouco apimentado do que excessivamente sem graça