Rust lidera teste de desempenho com IA, mas comparação entre linguagens é questionada
Um experimento que colocou versões do aplicativo de chat Campfire, criado originalmente com Ruby on Rails, frente a frente chamou a atenção de desenvolvedores. O projeto foi refeito em Rust, Go e Elixir com auxílio de agentes de inteligência artificial. Embora Rust tenha registrado os melhores números divulgados, a metodologia do teste passou a ser alvo de questionamentos.
David Heinemeier Hansson, criador do Ruby on Rails, apresentou os resultados algumas semanas depois de defender, na Rails World 2026, que os avanços da IA reduziram a necessidade de programadores escreverem código manualmente. Segundo ele, cada reimplementação do aplicativo levou apenas algumas horas.
Hansson não informou quais ferramentas ou modelos de IA foram usados. A tarefa, afirmou, foi favorecida pelo tamanho relativamente pequeno do código original do Campfire, desenvolvido principalmente em Ruby. Com uma base compacta, os agentes puderam analisar o funcionamento do sistema e gerar versões em outras linguagens em pouco tempo.
No teste de carregamento de uma página de sala, a implementação em Rust alcançou 36.260 requisições por segundo. Go chegou a 3.860, Elixir registrou 722 e Ruby on Rails marcou 241. Rust também ficou em primeiro lugar nos outros quatro cenários avaliados, que incluíam ações como pesquisar e publicar mensagens.
Os números alimentaram a tese de que migrar uma aplicação para Rust, especialmente com a ajuda de agentes de IA, pode trazer ganhos expressivos de velocidade. A publicação e o gráfico do experimento ultrapassaram 900 mil visualizações. Ainda assim, o próprio Hansson reconheceu que desempenho não é o único fator a considerar na escolha de uma tecnologia.
Rust pode exigir mais tempo de compilação e apresenta uma curva de aprendizado considerada difícil por parte dos desenvolvedores. Ruby, por sua vez, foi escolhido para o Rails com outra prioridade: facilitar a construção de software e aumentar a produtividade. Hansson criou o framework em 2003, enquanto trabalhava no Basecamp, aceitando que simplicidade e rapidez de desenvolvimento nem sempre resultariam na maior velocidade de execução.
As críticas ao benchmark se concentraram na diferença de tratamento entre as versões. Desenvolvedores apontaram que o código em Rust teria passado por uma rodada de otimizações mais intensa, enquanto as implementações em Go e Elixir permaneceram mais próximas do material produzido inicialmente pelos agentes. Se uma versão recebe mais ajustes do que outra, a comparação deixa de medir apenas as características das linguagens.
A engenheira do Google Jaana Dogan também contestou a interpretação dos resultados e afirmou que os números deveriam levar a uma análise cuidadosa do que o teste realmente avaliava. A dúvida central é se a vantagem observada veio da linguagem, da qualidade do código, das otimizações aplicadas ou de uma combinação desses fatores.
No caso de Elixir, programadores revisaram e reescreveram partes da implementação. Com as mudanças, o desempenho se aproximou do registrado por Rust. Em alguns cenários, a versão ajustada de Elixir chegou a superá-lo, mesmo depois de outras pessoas também terem otimizado o código em Rust. Defensores de Go fizeram uma objeção semelhante: o resultado pode refletir diferenças no esforço de aprimoramento, e não uma superioridade automática de uma linguagem.
Hansson respondeu que agentes mais avançados deveriam ser capazes de descobrir, por conta própria, como melhorar cada implementação. Na visão dele, se um sistema de IA não encontra as técnicas necessárias para acelerar o código em Elixir, essa dificuldade também é relevante em um cenário no qual agentes assumem uma parcela maior do trabalho de programação.
O episódio mostra que gerar uma aplicação funcional com IA não é o mesmo que produzir uma versão otimizada e pronta para competir em um teste de desempenho. A ferramenta pode acelerar a conversão entre linguagens, mas o resultado ainda depende de decisões técnicas, revisão e ajustes. Também é possível que um agente compreenda corretamente a lógica do programa sem explorar as melhores estratégias para reduzir o tempo de resposta ou o consumo de recursos.
Para comparar linguagens de forma mais justa, é importante estabelecer condições equivalentes. Isso inclui oferecer a cada implementação o mesmo tempo de desenvolvimento, aplicar critérios iguais de revisão e permitir um número semelhante de rodadas de otimização. Sem esse controle, o benchmark pode medir tanto a capacidade técnica das equipes ou dos agentes quanto o desempenho do software.
Outra medida essencial é repetir os testes em condições estáveis. Configuração do servidor, volume de dados, concorrência e características das requisições influenciam os resultados. Uma medição isolada pode favorecer determinada implementação por acaso ou revelar apenas como ela se comporta em um cenário muito específico.
Também convém avaliar mais do que requisições por segundo. Latência, uso de memória, consumo de CPU, estabilidade sob carga e facilidade de manutenção ajudam a determinar se uma solução é adequada para produção. Uma aplicação extremamente rápida, mas difícil de modificar ou operar, pode trazer custos maiores do que os benefícios que oferece.
A controvérsia não elimina o potencial da IA para acelerar reescritas e otimizações. Ela reforça, porém, que benchmarks produzidos a partir de código gerado por agentes precisam de regras transparentes e validação humana. Sem uma metodologia consistente, os números podem impressionar, mas não permitem concluir com segurança que uma linguagem será sempre mais rápida do que outra.