Go vs Rust en la época de la IA: lo medimos al compilar, al ejecutar y al mantener

Cuando un asistente de IA escribe buena parte del código, la pregunta ya no es en qué lenguaje se teclea más rápido. Importa cuánto tarda el compilador en revisar cada cambio, porque el agente repite ese ciclo decenas de veces; cuánto cuesta ejecutar lo que sale; y cuánto trabajo da mantenerlo dentro de cinco años. Para este Go vs Rust lo hemos medido con Go 1.27.3 y Rust 1.99.1, las versiones estables de hoy, escribiendo los mismos programas en los dos lenguajes y ejecutándolos en las mismas condiciones.

Go y Rust suelen aparecer juntos en la misma conversación, aunque nacieron para cosas distintas. Go lo presentó Google en 2009 para escribir servidores y herramientas de forma sencilla, con un recolector de basura y una compilación muy rápida. Rust, impulsado por Mozilla y con su versión 1.0 en 2015, busca la velocidad de C y C++ sin sus errores de memoria, a cambio de un compilador mucho más exigente. Ya contamos en qué lenguaje elegir cuando la IA escribe el código por qué la IA favorece a los lenguajes con tipos estrictos. Aquí bajamos al detalle con números propios.

El banco de pruebas es pequeño pero realista: una API REST de tareas en memoria, con validación, errores 400 y 404 y cuatro pruebas, escrita tres veces (Go solo con su biblioteca estándar, Go con Gin y Rust con axum). Además, tres programas clásicos de rendimiento con el mismo algoritmo en los dos lenguajes. Todo corre en contenedores con 4 núcleos de un AMD Ryzen 7 PRO 6850H, se repite varias veces y cada pareja de programas da exactamente la misma salida.

Claves de Go vs Rust en 2026

• En el bucle del agente, empate técnico: tras cambiar una línea, revisar los tipos tarda unos 100 ms en los dos. Compilar, 337 ms en Go y 405 ms en Rust. En un proyecto pequeño, ninguno frena a la IA.
• Desde cero, Go vuela si no hay dependencias: la API con la biblioteca estándar compila en 0.34 s. Con Gin sube a 10.75 s, más que Rust con axum (8.48 s en debug y 10.40 s en release): lo que pesa son las dependencias.
• Al ejecutar, Rust es más rápido y gasta menos: 1.5 veces en cálculo numérico, el doble en JSON y un 58 % más de peticiones por segundo en la API, con la tercera parte de latencia en el peor 1 % y menos de la mitad de memoria.
• Go gasta más CPU de la que parece: en la prueba que crea millones de objetos empatan en tiempo, pero Go usa el doble de CPU porque su recolector trabaja en paralelo en otros núcleos.
• Los frameworks de Go son más estables; los de Rust, más jóvenes: Go sirve una API con su biblioteca estándar, y Gin va por la versión 1.12. En Rust, axum (0.8), tonic (0.14) y sqlx (0.9) siguen por debajo de la 1.0.
• Mantenimiento: Go promete que el código de Go 1 sigue compilando y mantiene cada versión un año. Rust publica una versión cada seis semanas y agrupa los cambios incompatibles en «ediciones» que conviven entre sí.

Compilar: lo que nota un agente de IA

Un agente de programación trabaja en bucle: escribe un cambio, compila o revisa los tipos, lee los errores, corrige y pasa las pruebas. Cada vuelta suma el tiempo del compilador. Por eso medimos dos cosas: la compilación desde cero, que es lo que pagas al clonar un proyecto o en cada ejecución de integración continua sin caché, y lo que tarda cada paso después de cambiar una sola línea.

La versión de Go sin dependencias compila en un tercio de segundo, y por eso Go tiene fama de compilar «al instante». Pero Gin cambia la foto: arrastra 55 módulos y su compilación limpia pasa a 10.75 s, algo más que la de Rust en release. Varios de esos módulos llegan al binario aunque la API no los use, entre ellos clientes de QUIC, protobuf y el codificador BSON de MongoDB. En Rust, axum trae 48 crates y la compilación limpia ronda los 8.5 s en debug. Esa diferencia se paga una sola vez: después, ambos guardan lo compilado en caché.

En el bucle que de verdad repite un agente, la diferencia casi desaparece. cargo check, que revisa tipos y préstamos sin generar código, tarda 96 ms; go vet, 101 ms. Compilar cuesta 337 ms en Go y 405 ms en Rust, y la vuelta completa (linter, compilación y pruebas) se queda por debajo de un segundo en los dos, salvo con Gin. La sorpresa es que, en un proyecto pequeño, Rust ya no es el lenguaje lento de compilar. Ha ayudado que desde Rust 1.90 enlace por omisión con LLD, un enlazador mucho más rápido que el clásico de Linux.

Pero hay que leerlo con cuidado: es un proyecto de unas cien líneas. En proyectos grandes, Rust escala peor. En la encuesta sobre el rendimiento del compilador que hizo el propio proyecto Rust, con más de 3,700 respuestas, la queja más repetida fue justo esta recompilación tras un cambio pequeño, y el 55 % dijo esperar más de diez segundos por ella. Go se diseñó precisamente para compilar deprisa bases de código enormes, y en Rust lo normal es partir el proyecto en varias crates para que cada cambio recompile poco. Si el agente compila en release para medir rendimiento, también se nota: 1.36 s en Rust por cada cambio, sin compilación incremental.

Ejecutar: Rust gana, aunque no siempre por lo que parece

Para la velocidad usamos tres programas clásicos, escritos de forma idiomática y sin trucos de bajo nivel en ninguno de los dos lenguajes: n-body, que simula cinco planetas con cálculo en coma flotante; binary-trees, que crea y libera millones de pequeños objetos, y un tercero que convierte un millón de objetos a JSON (99 MB) y los vuelve a leer.

• Cálculo puro: Rust termina n-body en 1.99 s y Go en 3.06 s. El compilador de Rust, basado en LLVM, optimiza más a fondo este tipo de bucles numéricos.
• Muchos objetos pequeños: empatan en tiempo (unos 10.3 s), pero Go lo consigue porque su recolector de basura trabaja en paralelo en los otros núcleos: gasta 21 s de CPU frente a 10.2 s. Con un único núcleo, Go tarda 18.5 s. En un servidor compartido, esa CPU extra la pagas igual.
• JSON: serde_json hace el viaje completo en 0.76 s; Go, en 1.50 s con encoding/json y 1.42 s con el nuevo encoding/json/v2, que Go 1.27 ya incluye y que, según sus notas, lee JSON bastante más rápido. Rust también usa menos memoria: 588 MB frente a 736 MB.

Sirviendo la API, axum atiende unas 102,000 peticiones por segundo con dos núcleos, frente a unas 65,000 de Go. La mayor diferencia está en la cola: el 1 % de respuestas más lentas tarda menos de 1 ms en Rust y casi 3 ms en Go, porque no hay recolector que interrumpa. Y el proceso de Rust ocupa 5.8 MB en plena carga, frente a 14 MB de Go y 20 MB con Gin. Gin, por cierto, no aporta velocidad: rinde igual que la biblioteca estándar. Conviene no exagerar estas cifras: la prueba no toca ninguna base de datos, que en una aplicación real suele ser lo que más tarda.

Frameworks maduros: la ventaja de la biblioteca estándar

• Servidor HTTP y API. Go: net/http de la biblioteca estándar, con rutas por método y parámetro desde Go 1.22; y si se quiere framework, Gin 1.12, Echo 5.4, Chi 5.5 o Fiber 3.6. Rust: axum 0.8, del equipo de Tokio, y Actix Web 4.17; Rocket sigue en la 0.5.1, de mayo de 2024.
• Ejecución asíncrona. Go: incluida en el lenguaje, con gorutinas y canales. Rust: Tokio 1.54, con versiones de soporte largo (la 1.51 hasta marzo de 2027 y la 1.53 hasta septiembre de 2027).
• JSON. Go: encoding/json, v1 y v2, en la biblioteca estándar. Rust: serde 1.0 y serde_json 1.0, el estándar de hecho.
• gRPC. Go: grpc-go 1.84. Rust: tonic 0.14.
• Bases de datos. Go: database/sql en la estándar y GORM 1.31. Rust: sqlx 0.9 y Diesel 2.3.
• Dependencias de nuestra API. Go: ninguna con la estándar y 55 módulos con Gin. Rust: 48 crates con axum.

La gran baza de Go es que no necesitas un framework: su biblioteca estándar trae servidor HTTP, JSON, pruebas, criptografía y acceso a bases de datos, todo con la misma promesa de compatibilidad que el lenguaje. Nuestra API con la estándar ocupa 121 líneas, más o menos lo mismo que con Gin (113). En Rust casi todo vive en crates de la comunidad, muy buenas y muy usadas, pero varias piezas centrales del ecosistema web siguen por debajo de la 1.0. En el versionado semántico eso significa que cada versión «menor» puede romper la compatibilidad: pasar de axum 0.7 a 0.8 obligó a reescribir las rutas, de /:id a /{id}, entre otros cambios. Los cimientos sí son estables: Tokio, serde, hyper y clap ya pasaron la 1.0 hace años.

Para la IA esto tiene doble filo. Los modelos han visto muchísimo código de net/http, que apenas cambia; con crates que rompen su API entre versiones es más fácil que el asistente mezcle la sintaxis de una versión vieja con la nueva. El compilador de Rust lo detecta al instante, pero es una vuelta más del bucle.

Mantenimiento: estabilidad frente a evolución

• Compatibilidad. Go se compromete a que los programas escritos para Go 1 sigan compilando y funcionando sin cambios. Rust lo consigue de otra forma: los cambios incompatibles van en «ediciones» (2015, 2018, 2021 y 2024, esta última desde Rust 1.85) que cada crate elige, y crates de ediciones distintas funcionan juntas.
• Ritmo de versiones. Go saca dos versiones al año y corrige cada una hasta que salen dos más nuevas, así que tienes un año para actualizar. Rust publica una versión estable cada seis semanas y espera que actualices; su lema es «estabilidad sin estancamiento».
• Un solo estilo. Los dos traen formateador oficial (gofmt y rustfmt) y analizador (go vet y Clippy). Go añade una gramática mínima con pocas formas de hacer lo mismo, lo que facilita revisar código que no has escrito, generado o no.
• Despliegue. Los dos generan un único ejecutable. El de Rust es mucho más pequeño: 1.4 MB para nuestra API, frente a 6.7 MB con Go y 21.6 MB con Gin, ya sin símbolos de depuración.
• Herramientas para agentes. El servidor de lenguaje de Go, gopls, incluye desde la versión 0.20 un servidor MCP experimental para que asistentes como Claude Code o Gemini CLI consulten el código. En Rust, rust-analyzer da a los editores esa misma información, y los mensajes del compilador hacen buena parte del trabajo.

Cuál conviene cuando el código lo escribe una IA

La IA ha borrado la ventaja más visible de Go, que era lo fácil que resulta escribirlo: el código de Rust, más largo y exigente, ahora también lo genera la máquina, y su compilador se convierte en un revisor incansable. Al mismo tiempo, lo que sigue costando dinero y tiempo, ejecutar y mantener, es justo donde cada uno brilla de forma distinta. Rust conviene cuando el rendimiento, la memoria o la latencia se pagan cada mes (servicios con mucho tráfico, herramientas que se ejecutan millones de veces, sistemas embebidos) y el equipo puede leer lo que el agente escribe. Go conviene para servicios y herramientas de negocio en los que un equipo grande tiene que entender, revisar y actualizar el código durante años, con dependencias mínimas y compilaciones casi instantáneas incluso en proyectos enormes.

En nuestras pruebas, Rust fue entre 1.5 y 2 veces más rápido, sirvió un 58 % más de peticiones con menos memoria y, en un proyecto pequeño, no frenó más al agente que Go. Go respondió con compilaciones de un tercio de segundo, una biblioteca estándar que evita casi todas las dependencias y una promesa de estabilidad que Rust solo cumple en sus piezas centrales. Si vas a empezar con alguno de los dos, en decodigo.com tienes el curso de Go, el curso de Rust y guías para medir el rendimiento en Go y en Rust.

Mediciones propias del 21 de octubre de 2026: Go 1.27.3 y Rust 1.99.1 en contenedores con 4 CPU y 4 GB (AMD Ryzen 7 PRO 6850H), hyperfine y wrk; Gin 1.12.0, axum 0.8.9, tokio 1.54.0 y serde_json 1.0.154. Datos: notas de Go 1.27, política de versiones de Go, compatibilidad de Go 1, encuesta de Go 2025, servidor MCP de gopls; Rust 1.99.0, encuesta del rendimiento del compilador de Rust, Rust 1.90.0 y LLD, guía de ediciones de Rust, Tokio, axum 0.8; versiones de proxy.golang.org y crates.io. Logotipos: Go y Rust Foundation.