El lenguaje Goose, «más rápido que Rust»: cómo el benchmark se igualó tras una disposición de datos justa

El proyecto Goose está condenado a provocar una guerra de lenguajes: una IA escribió un lenguaje de programación que supuestamente es más rápido que C++ y Rust. Dejemos la guerra a los hinchas. Lo más interesante son los artefactos que quedaron tras la polémica: muestran cómo se construyen estas comparaciones y dónde se esconde el truco.

Qué encontró MrTeamlead

En dos vídeos, el bloguero MrTeamlead analiza el benchmark records_fixed.goose. Según los autores, Goose supera a la versión de Rust 1,8 veces en memoria y 1,9 veces en velocidad. El bloguero demuestra que el código de Rust puede acelerarse 6,7 veces si se añade paralelización.

El análisis del autor del artículo en Habr muestra que hay dos cambios clave:

• Vec::new() se sustituyó por Vec::with_capacity(N). El cambio es discutible: el benchmark simula un flujo de eventos y su número no se conoce de antemano.
• String se sustituyó por MyString, que almacena hasta 15 caracteres dentro del propio evento. Este cambio es legítimo.

En la versión de Goose, el texto está dentro del registro, mientras que en la de Rust está en el heap a través de String. Las disposiciones de datos son distintas, así que la comparación no es justa. Cuando el texto se colocó en Rust de la misma manera, el resultado fue 46,7 frente a 46,5 ms. En la práctica, el bloguero escribió el records_fixed.rs que faltaba.

Goose tiene además otro benchmark, records_var.goose, en el que la longitud de la palabra (4–15 letras) es un parámetro de la generación de datos y no un tamaño conocido por el código. Para ese caso, records.rs sigue siendo una pareja correcta. El autor de Goose respondió a las críticas que records_fixed era solo una ilustración y que el benchmark real es records_var. El archivo discutido lo retiró del repositorio.

Cómo gestiona Goose la memoria

La idea central son los data stacks. No son pilas de llamadas: no contienen marcos de función, solo datos. Se liberan como una pila: al salir del ámbito, la cima retrocede. La memoria se reserva por adelantado, pero se conecta al proceso de forma perezosa.

El compilador calcula en tiempo de compilación el número de data stacks a partir de la cadena de llamadas más profunda. Solo cuentan las funciones que mantienen arrays crecientes, y se necesita el número máximo de esos arrays vivos al mismo tiempo. Durante la ejecución no aparecen pilas nuevas, y una función que termina cede su pila a las llamadas siguientes. El precio de este enfoque son las restricciones para la recursión. En el momento de una llamada recursiva, la función no debe tener arrays crecientes vivos. Todo lo que deba sobrevivir a la llamada se crea fuera y se pasa por referencia.

Un ejemplo con un pedido de dos líneas (id, nombre del cliente, lista de productos) deja clara la diferencia:

• Goose: 29 bytes por pedido y cero asignaciones en el heap.
• Rust: 233 bytes al construirlo con collect y 153 tras shrink_to_fit(), más cuatro asignaciones en el heap.

Lo mismo puede hacerse en C, ya que Goose es un transpilador. Pero a mano resulta frágil: mirar se puede, modificar es arriesgado.

Qué significa en la práctica

La primera conclusión tiene que ver con la honestidad de las mediciones. Antes de comparar «el lenguaje A es más rápido que el lenguaje B», compruebe si los datos tienen la misma disposición. A menudo no gana el lenguaje, sino la ubicación de los datos en memoria. La segunda conclusión se refiere al vibe coding. Si una IA escribe el código y casi no hay tiempo para revisarlo, un lenguaje con memoria predecible, sin heaps ni asignadores, reduce el riesgo de acabar con una solución lenta por defecto. Para esos escenarios, Goose resulta más convincente que Rust, donde el código «ingenuo» acaba siendo ineficiente con facilidad.

Las limitaciones también importan. Goose gana donde hay muchas asignaciones de memoria y los cálculos se ejecutan en un solo hilo. Para igualarse en cómputo puro necesita bucles paralelos (par for) y vectorización (simd for), que aún están por implementar. Para tener una escala: el repositorio tiene menos de tres meses (agosto de 2026), mientras que Rust tardó cinco años y medio en llegar a rayon. Los problemas fundamentales del lenguaje, con todo, no han desaparecido.

La lección principal va más allá de un solo proyecto. Orca, de la que el autor del artículo habla al final, empezó en marzo de 2026 y acumuló casi 17 mil commits y más de seis millones de líneas de código, tests incluidos. Antes, un lenguaje así habría quedado como proyecto personal durante años. Ahora la velocidad con que se crean herramientas con IA es tal que los «cisnes negros» con forma de ganso se han hecho realidad. Y los benchmarks hay que volver a comprobarlos de inmediato.