Rust o Go para tu backend: cómo elegimos

Construimos sistemas en producción tanto en Rust como en Go, y nuestro propio producto funciona con los dos: Go donde importa la velocidad de iteración, Rust donde la latencia y la seguridad de memoria no son negociables. Así que, cuando alguien nos pregunta qué lenguaje usar para un backend nuevo, nuestra respuesta es: depende, y quien te responda con una sola palabra te está vendiendo algo.

Este artículo es la comparación que nos gustaría ver más a menudo: no un duelo de benchmarks, sino los compromisos prácticos que de verdad deciden la elección en proyectos reales.

Lo que tienen en común

Empecemos por lo que comparten, que es mucho. Ambos compilan a código nativo, ambos son lo bastante rápidos como para que el lenguaje rara vez sea tu cuello de botella, ambos generan un único binario estático que se despliega sin complicaciones en un contenedor y ambos ofrecen concurrencia de primer nivel y un ecosistema sano. Cualquiera de los dos es una elección defendible para un servicio backend. Te arrepentirás de elegir el «equivocado» mucho menos de lo que sugieren las discusiones en internet.

Dónde gana Go

Go optimiza sobre todo una cosa: que un equipo sea productivo y lo siga siendo. El lenguaje es tan pequeño que se aprende en una semana, la biblioteca estándar cubre casi todo lo que necesita un servicio y las goroutines hacen que el código concurrente resulte accesible en vez de aterrador. La compilación es casi instantánea, lo que mantiene corto el ciclo de retroalimentación.

• Servicios backend estándar: API REST y gRPC, microservicios, servicios de orquestación, workers.
• Equipos que necesitan avanzar rápido e incorporar a nuevos ingenieros con agilidad.
• Servicios de red con mucha concurrencia, donde las goroutines brillan y el runtime se encarga de la parte difícil.
• Todo aquello en lo que la sencillez y la legibilidad importan más que exprimir el último porcentaje de rendimiento.

El precio es que Go usa recolección de basura. Para la inmensa mayoría de los servicios no es un problema: el recolector es excelente. Pero implica pausas ocasionales y menos control sobre la disposición de la memoria, algo que importa en un tipo concreto de trabajo sensible a la latencia.

Dónde gana Rust

Rust te da un rendimiento a la altura de C, con seguridad de memoria y de hilos garantizada en tiempo de compilación, y sin recolector de basura. El borrow checker que frustra a los recién llegados es el mismo mecanismo que hace imposible publicar categorías enteras de errores: use-after-free, carreras de datos, desreferencias de punteros nulos. Cuando la corrección y la velocidad importan de verdad, esa garantía compensa una curva de aprendizaje más empinada.

• Software de sistemas y de red: protocolos, proxies, agentes, el plano de datos.
• Pipelines en tiempo real en los que una pausa del recolector es inaceptable, como los medios en directo.
• Componentes críticos para el rendimiento dentro de un sistema más grande, a menudo mediante FFI o como un servicio acotado.
• WebAssembly, donde Rust es un ciudadano de primera para llevar al navegador código a velocidad nativa.

El coste es real: Rust cuesta más de aprender, de escribir y de compilar. Un equipo que empieza con él irá más despacio durante los primeros meses. Esa inversión compensa en el ámbito adecuado y es pura sobrecarga en el equivocado.

Cómo elegimos de verdad

En nuestra propia plataforma, el reparto salió de forma natural: Go donde más importan la velocidad de iteración y la legibilidad, Rust donde la latencia y la seguridad de memoria no son negociables. No elegimos bando: ajustamos la herramienta a cada tarea.

Recurre a Rust cuando un fallo, una carrera de datos o una pausa del recolector sean de verdad inaceptables. Para casi todo lo demás, usa Go. La mayoría de los backends son «todo lo demás».

Una regla útil por defecto: empieza un backend nuevo en Go salvo que tengas un motivo concreto para no hacerlo, e introduce Rust de forma quirúrgica en los componentes que de verdad lo necesiten. No tienes que elegir un solo lenguaje para todo el sistema: un servicio en Go con un componente en Rust detrás de una FFI, o un pequeño servicio en Rust detrás de una API en Go, es una arquitectura perfectamente sensata.

Si estás sopesando esta decisión para un proyecto real y quieres una segunda opinión de quien publica software en ambos lenguajes, es justo el tipo de conversación que nos encanta tener.