Linguagem Goose "mais rápida que Rust": como o benchmark empatou depois de uma comparação justa do layout de dados

O projeto Goose está fadado à guerra de opiniões: uma IA escreveu uma linguagem de programação que supostamente é mais rápida que C++ e Rust. Deixemos a briga para os torcedores. O mais interessante são os artefatos que sobraram da discussão: eles mostram como essas comparações são montadas e onde mora a pegadinha.

O que o MrTeamlead descobriu

Em dois vídeos, o blogueiro MrTeamlead analisa o benchmark records_fixed.goose. Segundo os autores, o Goose supera a versão em Rust em 1,8 vez no uso de memória e em 1,9 vez na velocidade. O blogueiro mostra que o código em Rust pode ficar 6,7 vezes mais rápido com a adição de paralelização.

A análise do autor do artigo no Habr mostra que são duas as alterações principais:

• Vec::new() foi trocado por Vec::with_capacity(N). A mudança é questionável: o benchmark simula um fluxo de eventos, e o número deles não é conhecido de antemão.
• String foi trocada por MyString, que guarda até 15 caracteres diretamente dentro do evento. Essa mudança é legítima.

Na versão em Goose, o texto fica dentro do registro; na versão em Rust, fica no heap, via String. Os layouts de dados são diferentes, e por isso a comparação não é justa. Quando o texto foi colocado no Rust da mesma forma, o resultado ficou em 46,7 contra 46,5 ms. Na prática, o blogueiro escreveu o records_fixed.rs que faltava.

O Goose tem ainda outro benchmark, o records_var.goose, em que o tamanho da palavra (de 4 a 15 letras) é um parâmetro de geração dos dados, e não um tamanho conhecido pelo código. Para ele, o records.rs continua sendo um par correto. O autor do Goose respondeu às críticas dizendo que o records_fixed era apenas uma ilustração e que o benchmark de verdade é o records_var. Ele removeu o arquivo contestado do repositório.

Como o Goose lida com a memória

A ideia central são os data stacks. Eles não são pilhas de chamadas: não têm frames de função, apenas dados. A liberação funciona como numa pilha: ao sair do escopo, o topo recua. A memória é reservada com antecedência, mas só é conectada ao processo de forma preguiçosa (lazy).

O compilador calcula o número de data stacks em tempo de compilação, a partir da cadeia de chamadas mais profunda. Só entram na conta as funções que mantêm arrays dinâmicos, e o que importa é o número máximo desses arrays vivos ao mesmo tempo. Durante a execução, novas pilhas não surgem, e a função que termina entrega sua pilha às chamadas seguintes. O preço dessa abordagem são as restrições para recursão. No momento de uma chamada recursiva, a função não pode ter arrays dinâmicos vivos. Tudo o que precisa sobreviver à chamada é criado fora e passado por referência.

No exemplo de um pedido com dois itens (id, nome do cliente, lista de produtos), a diferença aparece de imediato:

• Goose: 29 bytes por pedido e zero alocações no heap.
• Rust: 233 bytes na montagem via collect e 153 após shrink_to_fit(), além de quatro alocações no heap.

O mesmo pode ser feito em C, já que o Goose é um transpilador. Mas fazer isso à mão é frágil: olhar é possível, mexer é perigoso.

O que isso significa na prática

A primeira conclusão diz respeito à honestidade das medições. Antes de comparar "a linguagem A é mais rápida que a linguagem B", verifique se os dados estão no mesmo layout. Muitas vezes quem ganha não é a linguagem, mas a forma como os dados são dispostos na memória. A segunda conclusão é sobre vibe coding. Se a IA escreve o código e quase não há tempo para revisão, uma linguagem com memória previsível, sem heaps e alocadores, reduz o risco de acabar com uma solução lenta por padrão. Para esses cenários, o Goose parece mais convincente que o Rust, em que o código "ingênuo" facilmente se torna ineficiente.

As limitações também importam. O Goose se sai melhor onde há muitas alocações de memória e a computação roda em uma única thread. Para empatar em computação pura, ele precisa de loops paralelos (par for) e vetorização (simd for), que ainda precisam ser implementados. Para ter uma noção de escala: o repositório tem menos de três meses (agosto de 2026), enquanto o Rust levou cinco anos e meio para chegar ao rayon. Os problemas fundamentais da linguagem, porém, não desapareceram.

A principal lição é maior que um único projeto. A Orca, citada pelo autor do artigo no final, começou em março de 2026 e acumulou quase 17 mil commits e mais de seis milhões de linhas de código, contando os testes. Antes, uma linguagem assim ficaria anos como projeto pessoal. Hoje, a velocidade de criação de ferramentas com IA é tal que os "cisnes negros" se tornaram realidade. Já os benchmarks precisam ser reverificados imediatamente.