Durante los últimos años, el nombre de Rust ha aparecido en conversaciones que, a priori, ni siquiera tenían que ver con este lenguaje. No es casualidad. Se citan casos de éxito llamativos —desde un servicio crítico de Discord reescrito con mejoras de rendimiento de «10 veces» hasta cuatro años de trabajo en Dropbox para migrar su motor de sincronización—, y se menciona cómo Microsoft ha empezado a introducir Rust en componentes de Windows con mejoras de rendimiento en torno al 5-15 % y, sobre todo, con la intención de atajar el enorme volumen de fallos de seguridad asociados a la gestión de memoria. Al mismo tiempo, hay voces que recuerdan que no todo proyecto necesita Rust: el propio equipo de TypeScript decidió portar a Go porque les resultaba más rápido y razonable para sus objetivos y plazos.
Este reportaje repasa, en lenguaje claro y con mirada crítica, qué es Rust en 2025, por qué entusiasma a tanta gente, cómo se compara con alternativas populares y, también, dónde tropieza. Sin hipérboles: rendimiento, memoria, ergonomía, tiempos de compilación, ecosistema y experiencia real al escribir código.
Memoria segura sin garbage collector: la promesa central
Rust es un lenguaje de programación de sistemas que promete algo que, durante décadas, pareció imposible: seguridad de memoria sin recolector de basura. En lenguajes como C o C++, es habitual ver errores del tipo use-after-free o fugas por una liberación indebida. Esos fallos no son anecdóticos: en Microsoft se ha llegado a atribuir aproximadamente el 70 % de los bugs de seguridad a problemas de este tipo.
Los lenguajes con garbage collector (Java, Python, Go, etc.) evitan buena parte de esa clase de errores, a costa de introducir pausas y cierta imprevisibilidad en la ejecución. Rust propone otra vía: propiedad y préstamos (ownership y borrowing) controlados por un comprobador de préstamos (borrow checker) que verifica, en tiempo de compilación, que el programa no usará memoria ya liberada ni incurrirá en carreras de datos. Si el código viola las reglas, no compila. El resultado teórico: rendimiento de C, seguridad de Java y un nivel de expresividad moderno.
El choque con la realidad: escribir Rust es diferente
Quien llega a Rust desde lenguajes con garbage collector suele vivir un proceso reconocible. Al principio, la sintaxis parece familiar, pero pronto aparecen mensajes del compilador que bloquean cambios aparentemente triviales: mantener una referencia a un elemento de un vector e intentar mutarlo, por ejemplo, dispara una alerta legítima. Esa resistencia inicial obliga a interiorizar la semántica de propiedad, préstamos y tiempos de vida.
No es una curva menor: muchos desarrolladores reportan entre 3 y 6 meses para sentirse cómodos con el borrow checker. En el camino, el compilador ayuda con mensajes de error inusualmente claros, y la herramienta de construcción Cargo se percibe como un acierto por su sencillez y coherencia. Aun así, no todo es idílico: los tiempos de compilación pueden ser ásperos; incluso proyectos pequeños pueden tardar 15-20 segundos en compilar, lo que rompe el ritmo a quien viene de hot reloads instantáneos.
Comparativa pragmática: C, C++, Go, Zig… y Rust
En una comparación práctica con una pequeña utilidad de línea de comandos escrita en C, C++, Rust, Go y Zig, afloran matices relevantes:
- C ofrece velocidad cruda y control total, a cambio de gestionar manualmente memoria (malloc/free) y asumir el coste de errores sutiles.
- C++ añade abstracciones modernas (vectores, smart pointers), pero paga el precio de una complejidad amplia: «hay seis formas» de hacer casi todo.
- Go apuesta por la simplicidad y compilaciones rápidas, sacrificando parte del control de bajo nivel y, según el caso, algo de rendimiento. La discusión sobre cuánto se pierde o no sigue abierta.
- Zig recuerda a C con mejoras de tooling y seguridad en compilación, pero su ecosistema aún es pequeño y su propuesta muy de bajo nivel.
- Rust busca el punto de equilibrio: control fino y seguridad garantizada en compilación. El peaje es pelear con el compilador al principio y asumir compilaciones más lentas.
La consecuencia práctica: en problemas con exigencia de rendimiento y seguridad, Rust brilla; para prototipos rápidos o equipos con plazos ajustados, quizá no sea la elección óptima.
Casos de uso que alimentan el entusiasmo
Los ejemplos de impacto han contribuido a la reputación del lenguaje:
- Discord reescribió un servicio crítico (lectura de estado) para eliminar picos de recolección de basura de 2 minutos que congelaban la aplicación en producción. El resultado fue un aumento de rendimiento de 10 veces y la eliminación de esas pausas.
- Dropbox dedicó cuatro años a reescribir su motor de sincronización de escritorio para gestionar cientos de miles de millones de archivos. La conclusión interna: Rust actuó como multiplicador de fuerza del equipo.
- Microsoft ha integrado Rust en componentes de Windows, con 152.000 líneas reescritas en áreas como el renderizado tipográfico, informando de mejoras del 5-15 % y, sobre todo, de un avance hacia la mitigación de los fallos de memoria que lastraban la seguridad.
- AWS desarrolló Firecracker, motor de virtualización ligera para serverless, en Rust.
- En desarrollo web, han surgido runtimes y frameworks escritos en Rust.
- En herramientas CLI, Rust ha impulsado utilidades como ripgrep, fd o bat, que muchos usuarios adoptan por su rapidez frente a equivalentes tradicionales de Unix.
Estos hitos muestran que la propuesta de valor de Rust no es solo teórica: hay cambios tangibles en producción.
¿Por qué no elegir Rust? El contraargumento que conviene escuchar
No obstante, el mismo ecosistema ofrece un recordatorio saludable: no todo necesita Rust. El caso del equipo de TypeScript es ilustrativo. Consideraron Rust, lo intentaron y les gusta el lenguaje, pero portar TypeScript a Rust les habría llevado años o habría exigido recurrir a mucho código unsafe o a estrategias de gestión de memoria propias. Eligieron Go por plazos y sencillez operacional, y completaron el esfuerzo en torno a un año.
El mensaje de fondo es pragmático: la idoneidad de Rust depende del contexto. Si un proyecto exige velocidad de llegada al mercado, un equipo pequeño y una curva de aprendizaje corta, Go puede encajar mejor. Si el proyecto se basa en un ecosistema maduro de C++ (por ejemplo, videojuegos), la inercia de bibliotecas y motores pesa mucho.
En palabras llanas: Rust triunfa en sus objetivos de diseño —seguridad y rendimiento—, pero no fue diseñado para que portar cierto tipo de bases de código Java fuera sencillo. Pretender lo contrario conduce a frustraciones y a retrasos difíciles de justificar.
Productividad real: lo que se gana y lo que cuesta
Lo que se gana
- Bugs de memoria que no llegan a producción: el compilador actúa como red de seguridad.
- Mensajes de error útiles: guían al desarrollador hacia la solución y convierten el aprendizaje en inversión.
- Cargo y un ecosistema de crates cada vez más sólido, especialmente en sistemas y CLI.
Lo que cuesta
- Curva mental: pensar en propiedad, préstamos y tiempos de vida es un cambio de paradigma. No es cuestión de inteligencia ni de años de experiencia, sino de encaje mental con el modelo de Rust. Hay junior que prosperan rápido y senior que se atascan semanas.
- Onboarding largo (3-6 meses): crea cuellos de botella si la organización espera productividad inmediata.
- Integraciones con legados: incorporar Rust a bases asentadas en Java, .NET o C++ puede resultar oneroso si no hay interfaz clara ni necesidad crítica.
- Tiempos de compilación: 15-20 segundos en cambios pequeños alteran la cadencia de iteración, sobre todo para quien depende del hot reload.
Ecosistema: maduro en sistemas y CLI; menos en GUI y machine learning
El ecosistema de Rust ha madurado donde su propuesta técnica encaja de forma natural: sistemas, herramientas de línea de comandos, runtimes, servicios de larga ejecución. En cambio, desarrollo de interfaces gráficas (GUI) y aprendizaje automático no muestran el mismo grado de madurez. La adopción no es uniforme, y eso importa cuando se valoran bibliotecas, documentación y ejemplos.
¿Es Rust “el lenguaje más admirado”? Qué significa eso en la práctica
Que Rust despierte admiración no es solo una percepción; es un fenómeno repetido en encuestas de desarrolladores. Traducido a la jornada a jornada, suele significar que quienes superan la curva inicial se sienten acompañados por el compilador, aprecian la coherencia de Cargo y valoran vivir con menos miedo a «ese bug de memoria imposible» que aparece el viernes a las 18:00.
La contracara existe: hay frustración con compilaciones lentas y con la opinión fuerte de las herramientas (Cargo es deliberadamente más rígido que sistemas de construcción ultra flexibles). Pero, para una porción creciente de equipos, la paz mental de no temer ciertos errores compensa sobradamente.
Dónde Rust es una gran idea… y dónde quizá no
Gran idea cuando:
- Se construyen servicios sensibles a seguridad y tiempos de ejecución largos.
- Hay presión por el rendimiento y cada milisegundo cuenta.
- Se valora detectar errores en compilación por encima de la rapidez de prototipado.
Quizá no cuando:
- El objetivo es prototipar rápido y llegar al mercado con iteraciones semanales.
- El equipo tiene plazos ajustados y no puede absorber 3-6 meses de aprendizaje.
- La base de código existente y su ecosistema (bibliotecas, motores, herramientas) empujan a otra tecnología.
La conclusión templada: menos grito, más caso de uso
Rust no es humo. Es una tecnología sólida que resuelve problemas reales a escala. Los datos de rendimiento y seguridad que acompañan a sus casos de uso son medibles. Pero la adopción tecnológica no es un juego de suma cero: problemas distintos requieren herramientas distintas y el contexto organizativo pesa más que cualquier benchmark aislado.
La pregunta relevante no es «¿debería usar Rust porque todos lo usan?», sino «¿qué problema estoy resolviendo y qué renuncias acepto?». Si la respuesta exige control de bajo nivel, seguridad de memoria sin pausas y robustez a largo plazo, Rust merece estar en la terna. Si el reto real es llegar antes, integrarse con un legado concreto o reducir riesgo de onboarding, puede que Rust no sea la mejor primera opción, por excelente que sea en sus propios términos.
Epílogo: lo que deja este ciclo de entusiasmo
El entusiasmo por Rust ha servido, además, para poner la seguridad de memoria en el centro. Que un gigante como Microsoft impulse Rust para componentes de Windows y plantee frenar nuevos proyectos en C/C++ es, en sí, un giro cultural. Que equipos como el de TypeScript expliquen con transparencia por qué no les encaja Rust, también es sano: madurez es elegir bien, no elegir lo de moda.
Rust, en definitiva, se está ganando su espacio allí donde su combinación única de rendimiento, seguridad y fiabilidad aporta valor empresarial claro. No necesita ser la opción universal para ser la opción correcta en muchos escenarios.
Preguntas frecuentes (FAQ)
¿Por qué Rust puede evitar el 70 % de los fallos de seguridad comunes?
Porque su modelo de propiedad y préstamos impide en compilación errores típicos de gestión de memoria (como use-after-free o dobles liberaciones) que, en C/C++, pasan el compilador y explotan en ejecución. Al no compilar programas con violaciones de seguridad de memoria, reduce drásticamente esa clase de vulnerabilidades.
Si Rust es tan seguro y rápido, ¿por qué un equipo como el de TypeScript eligió Go?
Por plazos y encaje técnico. Portar su base a Rust habría requerido años o el uso de mucho código unsafe y estrategias propias de gestión de memoria. Con Go lograron el objetivo en torno a un año. El mejor lenguaje es el que mejor resuelve el problema en el tiempo y con el equipo disponibles.
¿En qué tipos de proyectos Rust ofrece el mayor retorno?
En servicios críticos que requieren rendimiento sostenido y seguridad (p. ej., virtualización ligera, componentes del sistema, motores de sincronización, backends con altas exigencias). También en herramientas de línea de comandos donde la velocidad transforma el flujo de trabajo.
¿Qué debo considerar antes de apostar por Rust en un equipo nuevo?
Tres factores:
- Curva de aprendizaje de 3-6 meses hasta fluidez con el borrow checker.
- Integraciones con legados (Java, .NET, C++) y el coste de los puentes.
- Ritmo de desarrollo frente a compilaciones de 15-20 segundos incluso en cambios pequeños. Si ese coste es aceptable a cambio de seguridad y rendimiento, Rust encaja; si no, conviene valorar alternativas.
