Bun (runtime JS) está sendo portado em vibe de Zig para Rust

 (github.com/oven-sh)
1 pontos por GN⁺ 2 시간 전 | 2 comentários | Compartilhar no WhatsApp
  • O criador do Bun, Jarred Sumner, fez commit do guia de portabilidade Zig → Rust (PORTING.md) na branch claude/phase-a-port, revelando um experimento de grande escala de mudança de linguagem com uso de agentes de IA
  • A portabilidade é dividida em Phase A (tradução inicial apenas da lógica por arquivo, sem necessidade de compilar) e Phase B (passar na compilação por crate), fornecendo ao LLM cerca de 300 regras de mapeamento de tipos e idiomatismos
  • O próprio Sumner afirmou no Hacker News que "não está decidido que haverá um rewrite, e é muito provável que todo esse código seja descartado", então no momento trata-se de uma fase exploratória e experimental
  • Na comunidade, são citados como contexto o conflito com a política do Zig de proibir contribuições de IA após a aquisição pela Anthropic, o fato de o Bun já operar com um fork de Zig e as vantagens de segurança do ecossistema Rust
  • A maior parte dos PRs é gerada automaticamente por @robobun (bot de IA), enquanto CodeRabbitAI e Claude fazem a revisão, mostrando as possibilidades reais e os limites de uma grande migração de código guiada por IA

Estrutura principal do guia de portabilidade (PORTING.md)

  • O alvo da portabilidade é converter um arquivo Zig em um arquivo .rs no mesmo diretório; na Phase A, o objetivo é a reprodução fiel da lógica, independentemente de compilar ou não
  • É proibido usar crates externos de assíncrono e I/O como tokio, rayon, hyper, async-trait, std::fs, std::net — porque o Bun mantém seu próprio event loop e seus próprios syscalls
  • async fn é proibido; todo o processamento assíncrono deve ser mantido no mesmo modelo do Zig, com callbacks + máquina de estados
  • Partes incertas devem ser marcadas com // TODO(port):, e idiomatismos de Zig relacionados a desempenho com // PERF(port):, para tratamento na Phase B

Regras de mapeamento de tipos e idiomatismos

  • São fornecidas mais de 50 tabelas de mapeamento de tipos, como []const u8 → &[u8] (nunca &str), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error>
  • defer x.deinit() → remover e substituir por impl Drop, errdefer → usar scopeguard, comptime → converter para const generic, const fn e macro_rules!
  • Strings seguem o princípio de processamento baseado em bytes: é proibido usar std::string::String ou &str, devendo usar &[u8]/Vec<u8> — porque o Bun lida com WTF-8 e bytes arbitrários
  • @intCast → T::try_from(x).unwrap() (sempre verificar), @truncate → x as T (wrapping intencional), @bitCast → transmute, entre outras correspondências de funções embutidas do Zig para Rust

Mapa de crates e modelo de ownership

  • Namespaces Zig como @import("bun").X são mapeados 1:1 para cerca de 30 crates Rust, como bun_str, bun_sys, bun_jsc, bun_alloc
  • Crates de AST/parser mantêm a arena bumpalo::Bump; os demais crates removem parâmetros de allocator e usam o alocador global mimalloc
  • Mapeamento de ownership de ponteiros: bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T>

Reação da comunidade (Lobsters·HN)

  • Muitas opiniões questionam se "a ideia é realmente migrar para Rust ou apenas fazer um showcase do LLM da Anthropic"
  • Também há especulação de que o pano de fundo possa ser o conflito entre a política do Zig de proibir contribuições de IA e um workflow de desenvolvimento centrado em IA da Anthropic, embora alguns reconheçam que isso já entra no campo da teoria da conspiração
  • Há ceticismo sobre se um LLM consegue seguir fielmente cerca de 300 regras — mas também aparece a avaliação positiva de que "~16k tokens é um tamanho adequado para um subagente"
  • Uma observação interessante é que a abordagem de primeiro gerar código que não compila na Phase A vai na direção oposta do uso tradicional de agentes de código
  • O custo de manter o fork de Zig do Bun, as frequentes breaking changes do Zig e o risco de depender de uma linguagem ainda em beta para um produto central também são citados como possíveis motivações para a mudança

Leituras relacionadas

2 comentários

 
GN⁺ 1 시간 전
Comentários do Hacker News

  • Trabalho na Bun, e esse é o meu branch
    No geral, este tópico é um exagero. Houve 302 comentários sobre um código que nem funciona, mas ainda não foi decidido que haverá uma reescrita, e há uma chance bem alta de esse código inteiro ser descartado
    Quero ver como fica uma versão funcional, qual é a sensação, como é o desempenho e quão difícil é fazer isso passar pelo conjunto de testes da Bun e mantê-lo sustentável. Quero comparar lado a lado uma versão viável em Rust e uma em Zig

    • É uma pena ver algumas pessoas tendo uma reação eufórica só porque um único commit experimental foi colocado em um branch de experimento. Se deixarmos a emoção de lado por um momento e olharmos pelo mérito, imagino que muita gente também concordaria com a motivação de estudar esse tipo de abordagem
      A parte de “quão difícil é fazer isso passar pelo conjunto de testes da Bun e mantê-lo sustentável” é interessante numa época em que, a cada mês, surgem novas oportunidades de abstrair completamente o processo de portar código com agentes, e tudo isso é baseado em linguística
      Se quiser um caso parecido, igualmente interessante, vale ver o vinext, para o qual a Cloudflare portou o Next.js há alguns meses. No começo houve alguns problemas de adaptação, mas agora já está sendo usado em alguns projetos de produção sem grandes problemas
      [0] - https://github.com/cloudflare/vinext
    • Gosto do trabalho da Bun, mas tenho curiosidade sobre como vocês veem as preocupações recorrentes com a qualidade do projeto ultimamente. Parte disso pode ser o ódio típico de Twitter, mas também há problemas reais
      Parece legítimo as pessoas perguntarem por que adicionar processamento de imagem ou webview dentro de um runtime JavaScript enquanto bugs que afetam produção continuam largados. Por exemplo, um dos nossos maiores bloqueadores é https://github.com/oven-sh/bun/issues/6608, reportado em 2023, e ainda estamos sendo afetados 3 anos depois
    • Tenho curiosidade sobre qual é a principal motivação para avaliar Rust
      Só como referência, da última vez que usei Bun encontrei alguns bugs em partes como Bun.write em que Rust provavelmente teria ajudado
      [0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi...)
    • É uma pena ver uma reação tão grande contra uma pesquisa legítima. Para algumas pessoas, a Bun é vista como o projeto emblemático do Zig, especialmente entre quem tem antipatia por Rust e, por algum motivo, quer que Zig “vença Rust”
      No fim das contas, independentemente da linguagem ou da ferramenta, basta escolher o que melhor se encaixa no projeto e na situação. Pessoalmente, acho esse experimento interessante e tenho curiosidade de ver como ele vai evoluir. Para usar Rust idiomático, é preciso uma mudança de mentalidade, então também vale observar o quanto um LLM consegue se adaptar a isso com o tempo
    • Tenho uma curiosidade tranquila sobre o resultado
      Espero que o código fique elegante e, além de apenas sustentável, seja preparado para o futuro e com bom desempenho

  • É interessante ver isso enquanto o post no topo do HN agora fala em preocupação com a Bun por causa da aquisição pela Anthropic. O principal comentário por lá tinha um tom de “a Anthropic faz experimentos na própria base de código, não é como se o time da Bun fosse fazer esse tipo de experimento de vibe coding”
    Só que o que estamos vendo agora parece justamente um grande trabalho feito com vibe coding
    O tempo vai dizer como isso termina, mas seria bom se os mantenedores da Bun explicassem o que estão fazendo aqui e por quê

    • Recentemente tentaram contribuir melhorias de volta para o Zig, mas foram barrados porque o Zig tem uma regra rígida contra código de IA. Fica a critério de cada um decidir se essa reação é uma forma de pressionar o Zig ou se a mudança tem motivos práticos
      Provavelmente é um pouco dos dois
    • Talvez isso não seja um trabalho tão grande quanto parece. Nas últimas semanas fiz um experimento de reescrever o Postgres em Rust com IA, e ela foi muito boa nesse tipo de trabalho de reescrita
      Quando há uma base de código existente para usar como referência, muitos dos problemas do vibe coding diminuem. Já existe uma arquitetura funcional e também um conjunto de testes para comparar
      Em um mês saí do zero para um estado que passa por mais de 95% do conjunto de testes do Postgres. Se Jarred é a pessoa que criou a Bun, imagino que ele consiga ir muito mais rápido
      [0] https://github.com/malisper/pgrust
    • Não sei se há gente em comum entre esses times, mas a própria Anthropic parece estar investindo bastante no ecossistema Rust
      Recentemente propuseram algumas ferramentas internas como implementação oficial em Rust do Connect RPC. É um conjunto de bibliotecas baseadas em Protobuf, então inclui também o Buffa, um novo compilador de Protobuf baseado em Rust
      [0]: https://github.com/orgs/connectrpc/discussions/7#discussionc...
      [1]: https://connectrpc.com/
      [2]: https://github.com/anthropics/buffa
    • O Claude provavelmente lida melhor com Rust do que com Zig
    • Não vejo por que isso precisaria ser explicado. Isso só parece trabalho de base para uma refatoração inicial e uma eventual migração de linguagem, e ainda nem foi decidido de fato que vão trocar Zig por Rust
      Se você é investidor e quer saber se o tempo está sendo bem usado, eu entendo, mas fora isso não vejo por que isso seria importante para os outros

  • É interessante como os tempos mudaram. Em 2015, o runtime inteiro do Go, que já era uma base de código madura, foi semi-automaticamente reescrito de C para Go. Um dos mantenedores criou uma ferramenta de conversão de C para Go voltada ao subconjunto de C que eles usavam, de modo que compilasse e gerasse a mesma saída, e depois humanos revisaram o código resultante para deixá-lo mais idiomático em Go e mais otimizado
    Agora você pode simplesmente pedir isso a um modelo de linguagem
    Slides:
    https://go.dev/talks/2015/gogo.slide#3
    Há uma semelhança curiosa também

    We had our own C compiler just to compile the runtime.
    O time da Bun também mantém um fork próprio do Zig

    • A grande diferença aqui é que a ferramenta de C para Go provavelmente era determinística. Se rodassem várias vezes, o resultado seria exatamente o mesmo
      Como humanos escreveram, entenderam, testaram e depuraram a ferramenta de conversão, era possível confiar no resultado
      LLMs são não determinísticos. Se você pedir a conversão 10 vezes de forma independente, vai obter 10 resultados diferentes, e alguns podem ser bem distintos. Não há como validar sem revisar tudo por completo a cada vez
      Isso não quer dizer que uma ferramenta determinística feita por humanos seja perfeita ou livre de erros, mas dá para construir muito mais confiança nela do que em um LLM

  • O commit linkado não parece muito convincente para sustentar esse título. Existe um branch em que o Claude está fazendo uma grande reescrita de código Zig para Rust e, no momento, ele está em 773.950 linhas adicionadas e 151 linhas removidas
    [0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port

    • Assustador. Quando o Jarred saiu da Stripe pela primeira vez, ele também deixou vários PRs com mais de 10 mil linhas reescrevendo código de dashboard, e isso levou meses para ser resolvido. Uma diferença de 750 mil linhas é praticamente impossível de revisar

    • Fiquei curioso com o tamanho desse trabalho e peguei os 5 principais segundo o cloc

      Language files blank comment code

      Zig 1298 79693 60320 571814
      TypeScript 2600 67434 115281 471122
      JavaScript 4344 36947 37653 290873
      C++ 583 27129 19117 215531
      C 111 21577 83914 199576

  • Uma abordagem mais lenta, mas com chance de funcionar, que me vem à cabeça seria seguir o histórico de commits do git como uma fase de lockstep, aplicando a intenção comportamental de cada commit
    Se fizessem isso, eu também gostaria de saber se certos commits de correção de bugs poderiam ser pulados porque a implementação em Rust evitou o problema

    • Ideia interessante, e talvez desse para testar isso em um projeto menor primeiro. A Bun tem mais de 15 mil commits, então, para não depender de milhares ou dezenas de milhares de chamadas de API, seria preciso uma forma de processar blocos de commits em um único prompt
    • O issue tracker da Bun tem muitos segmentation faults. Indo para Rust, provavelmente escapariam de uma boa parte deles

  • Considerando que recentemente Bun/Anthropic demonstraram insatisfação com os tempos de compilação do Zig, ou seja, dado que um PR com melhoria de 4x na velocidade de compilação feito por vibe coding não foi aceito, tentar migrar para uma linguagem que provavelmente tem tempos de compilação 4x piores do que o Zig base parece um movimento “interessante”

    • Sou extremamente cético quanto à ideia de que o Zig de fato compila mais rápido que Rust
      Já escrevi código parecido em Zig e em C++, e compilação fria em C++ foi várias vezes mais rápida, enquanto compilação incremental em C++ terminava instantaneamente
      Acho que a principal razão para projetos Rust compilarem devagar é o uso excessivo de dependências e o abuso de metaprogramação no código
      O Zig não tem várias unidades de compilação, então não há paralelização da compilação

  • Estou muito curioso para ver como essa migração por IA vai terminar. Estou envolvido em vários projetos ativos em que a linguagem ou o framework estão atrapalhando, mas eles são grandes demais para serem reescritos só com esforço humano
    Tive mais sucesso com vibe coding em Rust do que em linguagens dinâmicas. Parece que o rigor do compilador Rust força o agente de IA a produzir código melhor. Não tenho certeza; pode ser só porque sou menos familiarizado com Rust e isso me dá a impressão de que ele está indo melhor

    • Rust é uma boa escolha para deixar LLMs trabalhando sem muita supervisão. Pela minha experiência, você precisa monitorar fortemente o progresso, e um humano precisa manter a propriedade do design daquilo que está sendo criado ou portado
      Um test harness é essencial. É preciso rodar testes a cada iteração para garantir que outra parte não foi quebrada
      No momento estou portando TypeScript para Rust e aprendi bastante no processo. O trabalho em andamento pode ser visto aqui https://github.com/mohsen1/tsz/
      Posso compartilhar o que aprendi
    • Em alguns trabalhos, estou escolhendo Go como alvo em vez de Rust. Ainda assim, de forma parecida, embora eu não seja programador Go, parece estar funcionando bem o bastante. Mas também não estou abordando isso de forma completamente ingênua, porque já lidei com bases de código variadas por décadas
      A forma como compenso minha limitação de não conseguir revisar o código em detalhe é garantir que testes, testes de integração e testes end-to-end cubram tudo com que me importo. Sem isso, não há como ter confiança de que o trabalho detalhado não pulou etapas
      Também peço benchmarks e testes de estresse, e faço a base de código ser analisada em busca de possíveis gargalos. Depois de encontrar e corrigir alguns problemas, a situação melhorou. Por fim, fazer uma revisão crítica, buscar oportunidades de refatoração etc. costuma gerar uma boa lista do que corrigir em seguida
      Também é uma boa estratégia rodar verificadores de vazamento de memória e ferramentas de análise estática. Se esse tipo de abordagem reduz a quantidade de problemas encontrados, então o código provavelmente não está horrível. Pelo menos chegou a algum ótimo local
      A falta de revisão de código soa bem assustadora, mas em programação assistida por IA ela está rapidamente se tornando o maior gargalo. Eliminar esse gargalo assusta, mas aumenta em vários níveis a quantidade de código possível. Compiladores rígidos e gerenciamento estrito de memória ajudam a remover algumas categorias de bug
      Antes eu fazia esse tipo de trabalho em linguagens que eu entendia. Quando você começa a lidar rotineiramente com commits maiores, revisão vira um problema
      Acho que esse tipo de trabalho em grandes bases de código vai ficar muito mais fácil e melhor com o tempo. Os principais aborrecimentos nesse tipo de engenharia são a tendência do modelo a pegar atalhos deliberadamente, testar só o caminho feliz e empurrar o trabalho central para depois
      Muitos modelos parecem enviesados a economizar uso de tokens. Isso é bem irritante, mas é fácil compensar com prompts de acompanhamento e testes, e deve se tornar um problema menor conforme os modelos forem ajustados para se comportar melhor sem prompts extras
    • Isso é efeito Dunning-Kruger. Mas pelo menos você reconheceu
    • Sim, ele gera código Rust ruim
      Sobre “pode ser só porque sou menos familiarizado com Rust e isso me dá a impressão de que ele está indo melhor”, acho bem possível

  • Torço para o Zig dar certo, mas como ainda não é 1.x, imagino que uma base de código grande como a da Bun tenha dificuldade para lidar com grandes mudanças incompatíveis
    Além disso, a Bun usa um fork do Zig https://x.com/bunjavascript/status/2048427636414923250?s=20

  • Não entendo por que não reescrevem o claude-code em Rust
    A Anthropic adquiriu o time da Bun porque o claude-code usa Bun e, ao que tudo indica, talvez queiram portar a Bun de Zig para Rust porque Rust é “melhor”. Em outras palavras, a ideia seria tornar o claude-code “melhor”, então não entendo por que fazer isso de um jeito tão complicado
    Dada a capacidade de LLM que eles têm, poderiam simplesmente escrever o claude-code diretamente em Rust e deixá-lo no melhor estado possível

    • Eles não devem ter caído no próprio marketing “grassroots” exageradamente explícito, e qualquer ótimo engenheiro sabe que LLM não é a ferramenta certa para esse trabalho
      A Bun também pode ser vista facilmente como truque de marketing
    • Pelo que sei, o claude code é React renderizado como UI de terminal. Parece que eles realmente querem usar React. Talvez seja isso que acontece com o cérebro quando se usa IA demais

  • Até agora, a surpresa com claude/codex esteve em grande parte limitada a aplicações construídas dentro das condições de contorno de bibliotecas existentes. Os modelos aproveitam diretamente grandes obras humanas já feitas até aqui, como Python, requests, ffmpeg
    Mas estou esperando o momento em que o monstro vá além dessas restrições: reescrevendo, remendando, renomeando e reconstruindo bibliotecas, DLLs e binários. Quando isso acontecer, as bibliotecas vão se dissolver, e as aplicações ficarão mais eficientes, seguras e integradas, mas flutuando sobre areia movediça de uma pilha tecnológica totalmente inumana
    Em termos de interpretabilidade ou segurança, isso certamente parece uma ideia horrível, mas também é difícil afirmar que não pode funcionar, especialmente se houver um esforço centralizado e dedicado por trás. Também não está claro se essa slopificação total de décadas de desenvolvimento básico e incremental reescrito inteiramente por máquinas é necessariamente incompatível com interpretabilidade
 
GN⁺ 2 시간 전
Opiniões no Lobste.rs

  • Só para constar, o que Jarred Sumner disse no HN sobre isso foi o seguinte: ele trabalha no Bun, essa é a branch dele, e a posição dele é que esta thread é uma reação exagerada a um código que não funciona
    Ainda não foi decidido que haverá uma reescrita, e há uma chance bem alta de esse código todo simplesmente ser descartado
    A ideia é ver como fica uma versão funcional, como é o desempenho, qual é a dificuldade de fazê-la passar na suíte de testes do Bun e torná-la sustentável em termos de manutenção, e comparar lado a lado uma versão viável em Rust e uma em Zig

    • Isso me faz lembrar do ditado: “uma mentira dá meia volta ao mundo enquanto a verdade ainda está calçando os sapatos”
      Interpretações pop de tecnologia costumam depender muito de reações imediatas

  • Até os pull requests normais do Bun já são uma bagunça considerável: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
    A maioria é criada de forma autônoma pelo @robobun, verificando duplicações com GitHub Actions (baseado no Claude), e @coderabbitai e @claude fazem a revisão
    Enquanto isso, o CI está quebrado, e o @robobun acaba fechando alguns dos próprios PRs por considerar que duplicam outros PRs feitos por ele mesmo
    O merge na main ainda é feito por humanos

    • Isso eu não esperava
      Eu lembrava do Bun como algo elogiado pela obsessão por performance do Jarred, mas não imaginava que deixariam LLMs correr tão soltas assim na codebase

  • Isso é absurdo
    Pelo “mapeamento de idioms”, está tudo coberto de unsafe, e parece muito provável que saia uma grande quantidade de código nada idiomático em Rust
    O mapeamento de @fieldParentPtr("field", ptr) em especial parece grosseiro
    Dito isso, a “fase A” parece ser basicamente uma tradução linha por linha, e depois a intenção parece ser refatorar com prompts para chegar a um Rust mais idiomático e sustentável
    O problema é que o design da linguagem pode empurrar fortemente a direção da implementação, e de fato empurra, então há uma boa chance de surgirem nós difíceis de desfazer depois
    No fim, parece que a velha reescrita manual teria sido um caminho melhor

    • Tornar isso em código idiomático e seguro talvez seja algo que o LLM consiga fazer na próxima etapa
      Especialmente com o nível de recursos da Anthropic, a parte conveniente da IA é que ela não se cansa de refatorar o mesmo código repetidamente

  • Independentemente da migração em si, o método que eles escolheram é particularmente interessante
    O docs/PORTING.md linkado tem cerca de 300 regras de portabilidade, e isso parece ser regras demais para qualquer LLM “lembrar” e seguir com fidelidade de ponta a ponta
    Como a Anthropic é dona do Bun, esse port deve ter na prática um orçamento infinito de tokens, e talvez eles estejam tentando “garantir” que tudo foi seguido levantando algo como número de arquivos * número de regras agentes
    Eles também dividem o port em duas etapas: A faz um port grosseiro de cada arquivo de forma isolada e já esperando que a compilação quebre; B conecta tudo e faz compilar
    Na fase A, dizem explicitamente ao agente que o código “não precisa compilar”, e fazem cada arquivo portado receber uma nota de baixa/média/alta conforme a qualidade da saída
    Baixa significa lógica errada, média significa lógica correta mas sem compilar, e alta significa lógica correta e aparentemente compilável
    Isso é o exato oposto da forma como eu entendo e uso agentes de programação, então estou curioso com o resultado
    Pela minha intuição, dizer que não precisa compilar e não dar um “objetivo final” claro torna o resultado muito imprevisível, e na fase B alguém vai acabar tendo que revisar uma montanha de código pouco confiável
    Dei um grep rápido e, entre 1279 dessas notas de qualidade de saída, cerca de 3% eram baixas, 80% médias e 17% altas

    • Em maio de 2026, 300 regras parecem razoáveis
      O PORTING.md tem cerca de 16k tokens e está focado na tarefa principal
      Para novos subagentes, isso não parece ruim e talvez seja até ideal

  • Fico me perguntando se o objetivo real é mesmo migrar para Rust ou se isso é um teste dos LLMs da Anthropic

  • Parece bem interessante
    O conjunto de regras que precisa ser aplicado de uma vez parece impossível de validar sem passar por um ciclo gigantesco de code review
    Tokens eles devem ter, mas depois de uma transformação dessas parece que validar o código de fato fica extremamente difícil
    Se os testes também tiverem que passar pelo mesmo processo, fica a dúvida sobre o que realmente sobra como fonte de verdade
    Ainda assim, como experimento, é impressionante

  • Quando olho para como andam os matadores do Node.js, o Deno ofereceu melhorias marginais como sistema de permissões e suporte nativo a TypeScript, mas não abalou o mundo, e esses recursos estão até sendo reimportados para o Node.js
    Pela minha experiência, a experiência de desenvolvimento não era significativamente melhor, e em alguns casos era até pior por causa de ferramentas excelentes como o pnpm
    Pode até ser mais rápido, mas nos últimos 5 ou 6 anos eu não senti problemas de performance do Node.js no meu contexto de uso
    O JSR também não mudou o mundo, e a comunidade acabou criando o npmx, que oferece uma experiência melhor
    Ainda assim, a biblioteca padrão do Deno, por exemplo @std/collections, é bem boa e eu uso
    O Bun sempre pareceu arriscado por tentar abraçar coisa demais, mas eu estava cautelosamente otimista porque parecia que o Jarred queria construir o melhor runtime JS generalista, mesmo que isso levasse anos
    Só que, depois da aquisição pela Anthropic, vendo o Jarred agora fazer bastante ~~vibe coding~~ desenvolvimento orientado por agentes, e agora com essa notícia de vibe porting, ficou claro para mim que, mesmo sendo uma branch experimental, não é um projeto que eu usaria
    Então o Node.js continua reinando
    Falando sério, os recursos embutidos de TypeScript e SQLite são impressionantes
    Não sou totalmente anti-IA; acho divertido e útil fazer vibe coding de um pequeno script em Python ou de uma webapp para resolver um problema bem específico
    Mas, em projetos complexos com muitas partes móveis e usuários, minha convicção de que o “desenvolvimento orientado por agentes” em larga escala é um prejuízo líquido só se fortalece repetidamente, mesmo que acelere temporariamente a entrega de funcionalidades, porque no fim desestabiliza e infla o projeto
    Penso em exemplos como VSCode, Cursor, mise e a interface web do Perplexity
    É tão difícil assim fazer um dropdown em JS que não fique engasgando ao rolar?
    Espero que mais ferramentas, bibliotecas e projetos grandes dos quais eu dependo percebam isso e adotem políticas anti-IA mais rígidas

  • É literalmente a direção errada
    Nunca vi sequer um mantenedor de Rust que cuida de um projeto de porte médio, ou seja, com centenas de milhares de linhas ou mais, dizer que está satisfeito com a escalabilidade em codebases grandes

    • Prazer
      Acho o Rust especialmente excelente para codebases grandes:
      https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
      https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
      Só que, para lidar com isso de forma eficiente, é preciso saber minimamente o que se está fazendo:
      https://matklad.github.io/2021/09/05/Rust100k.html
      Nesse contexto, não sei bem como o Zig se compara ao Rust
      O TigerBeetle tem uma abordagem de design bem particular
    • Dando um pouco de contexto, já mantive algo como seis codebases Rust na faixa de 10 mil a 100 mil linhas, mas nenhuma acima de 100 mil
      Também conheço alguns casos em que um programa em Rust com 20 mil linhas implementava a funcionalidade central de um programa em Go com 300 mil linhas
      Então isso não corresponde exatamente ao critério que você colocou
      Mas, na faixa de 10 mil a 100 mil linhas, como mantenedor, fiquei muito satisfeito com Rust
      Esse tamanho é pequeno o suficiente para que o programa continue bem focado, mas grande o bastante para implementar de forma séria uma ideia central
      Nessa escala, tanto a linguagem quanto as ferramentas foram um grande trunfo, pelo menos na minha experiência pessoal
    • O cargo-nextest atualmente tem 84 mil linhas de código Rust, excluindo comentários e linhas em branco, e como mantenedor único eu considero impossível escrevê-lo em outra linguagem mantendo meu padrão pessoal de qualidade

  • Talvez seja por isto: https://github.com/oven-sh/bun/issues/28001

    • Eu gostaria que explicassem exatamente como o Rust teria evitado isso
      Isso não é um problema de segurança temporal de memória