Rust no nació para ganar una guerra cultural entre programadores. Nació para resolver un problema muy concreto: escribir software de bajo nivel con el rendimiento de C y C++, pero sin buena parte de sus errores de memoria. Dos décadas después de que Graydon Hoare empezara a trabajar en el lenguaje como proyecto personal dentro del entorno de Mozilla, Rust se ha convertido en una de las apuestas más serias de la industria para reducir vulnerabilidades en sistemas críticos.
Su historia tiene todos los elementos de una buena narración tecnológica: un origen casi doméstico, una comunidad muy intensa, una empresa que lo incubó y luego dejó de sostenerlo como antes, una fundación creada por gigantes tecnológicos y una entrada lenta, conflictiva y simbólica en territorios donde C parecía intocable. Windows, Android y Linux no han abandonado C ni C++, pero sí han abierto la puerta a Rust en partes cada vez más sensibles.
La palabra “venganza” funciona como gancho, pero se queda corta. Lo que ha ocurrido con Rust no es una revancha de programadores despedidos. Es algo más profundo: la industria ha aceptado que los parches, mitigaciones y auditorías no bastan para contener una clase de errores que lleva décadas provocando fallos, exploits y actualizaciones de seguridad. Rust se ha impuesto no por moda, sino porque el coste de seguir igual se ha vuelto demasiado alto.
Un lenguaje nacido del hartazgo con los fallos de memoria
La historia más repetida sobre Rust empieza en 2006, con Graydon Hoare subiendo escaleras en Vancouver porque el ascensor de su edificio volvía a fallar. El detalle ha sido contado tantas veces que casi parece una fábula, pero resume bien la frustración que dio origen al lenguaje: software aparentemente pequeño, escrito en lenguajes potentes, podía fallar de forma absurda por errores en la gestión de memoria.
C y C++ han sido durante décadas la base de sistemas operativos, navegadores, drivers, bases de datos, compiladores, videojuegos y software embebido. Son rápidos, flexibles y permiten controlar la máquina con enorme precisión. También permiten cometer errores peligrosos: desbordamientos de búfer, accesos fuera de límites, use-after-free, dobles liberaciones de memoria o referencias colgantes.
Rust intenta mantener el control de bajo nivel, pero cambia las reglas. Su sistema de propiedad, préstamos y tiempos de vida obliga al compilador a verificar que el código no accede a memoria inválida ni introduce carreras de datos en condiciones que el lenguaje puede comprobar. Ese mecanismo, conocido como borrow checker, es una de sus mayores virtudes y también una de las razones por las que muchos desarrolladores lo encuentran duro al principio.
| Problema clásico en C/C++ | Qué intenta evitar Rust |
|---|---|
| Buffer overflow | Accesos fuera de los límites permitidos |
| Use-after-free | Uso de memoria ya liberada |
| Double free | Liberación repetida de una misma zona |
| Punteros colgantes | Referencias a datos que ya no existen |
| Data races | Accesos concurrentes inseguros |
| Null pointer dereference | Uso indebido de referencias nulas |
Rust no elimina todos los errores. Tampoco convierte automáticamente a cualquier programa en seguro. Existe unsafe, hay dependencias, FFI con C/C++ y problemas lógicos que ningún compilador puede evitar. Pero sí reduce de raíz una de las familias de vulnerabilidades más persistentes del software moderno.
Mozilla, Servo y la primera gran oportunidad
Mozilla empezó a patrocinar Rust oficialmente en 2009. El lenguaje encajaba con una preocupación real dentro de Firefox: los navegadores son piezas enormes, expuestas a contenido no confiable y escritas en gran parte en C++. Si un motor de renderizado procesa millones de páginas distintas, cualquier error de memoria puede convertirse en una puerta de entrada para un atacante.
De esa ambición nació Servo, un motor de navegador experimental pensado para aprovechar Rust, paralelismo y seguridad de memoria. Durante años, Rust y Servo crecieron juntos dentro de Mozilla. El lenguaje fue madurando, dejó atrás cambios constantes y alcanzó su versión 1.0 en 2015. Ese lanzamiento fue clave porque prometía estabilidad hacia atrás, algo imprescindible para que una empresa se planteara usarlo en producción.
| Hito | Año | Importancia |
| Graydon Hoare inicia Rust como proyecto personal | 2006 | Primer diseño del lenguaje |
| Mozilla patrocina oficialmente Rust | 2009 | El proyecto gana recursos y equipo |
| Rust 1.0 | 2015 | Estabilidad para adopción real |
| Despidos en Mozilla | 2020 | Incertidumbre sobre el futuro del proyecto |
| Rust Foundation | 2021 | Gobierno y financiación más independientes |
| Rust entra en Linux 6.1 | 2022 | Primer soporte dentro del kernel |
| Google escala Rust en Android | 2021-2025 | Uso creciente en componentes nativos |
| Microsoft introduce Rust en partes de Windows | 2023 en adelante | Validación en software de sistema masivo |
La paradoja llegó en 2020. Mozilla anunció un recorte de unas 250 personas, alrededor de una cuarta parte de su plantilla. Los despidos afectaron a equipos vinculados a Servo, WebAssembly, Rust y otros proyectos. Para muchos observadores, aquello parecía un golpe durísimo: el lenguaje que Mozilla había incubado quedaba sin el respaldo corporativo que lo había acompañado durante años.
Pero Rust ya era más que Mozilla. La comunidad había crecido, grandes empresas lo estaban usando y el problema que intentaba resolver no había desaparecido. Al contrario, se estaba volviendo más visible.
La Rust Foundation y el momento en que los gigantes entendieron el riesgo
En febrero de 2021 se creó la Rust Foundation, con AWS, Google, Huawei, Microsoft y Mozilla como miembros fundadores. El mensaje era claro: Rust ya no podía depender de una sola empresa. Si varias tecnológicas estaban construyendo servicios, herramientas e infraestructura sobre ese lenguaje, también debían ayudar a sostenerlo.
Este paso cambió la percepción del proyecto. Rust dejó de parecer una rareza de Mozilla y pasó a tener una gobernanza más independiente, con apoyo económico de compañías que competían entre sí pero compartían una preocupación: la seguridad y fiabilidad del software de sistemas.
El motivo de fondo era un número incómodo. Durante años, Microsoft señaló que alrededor del 70 % de las vulnerabilidades a las que asignaba CVE estaban relacionadas con seguridad de memoria. Google ha dado cifras similares para Android en su propia trayectoria: en 2019, los errores de memoria representaban el 76 % de las vulnerabilidades de Android; en 2024, esa proporción había bajado al 24 %.
| Organización | Dato relevante sobre seguridad de memoria |
| Microsoft | Alrededor del 70 % de sus vulnerabilidades CVE durante años procedían de errores de memoria |
| Google Android | Del 76 % de vulnerabilidades de memoria en 2019 al 24 % en 2024 |
| NSA | Recomienda usar lenguajes seguros en memoria cuando sea posible |
| Rust Foundation | Agrupa a grandes actores para sostener el lenguaje |
| Linux | Integra soporte inicial para Rust desde la versión 6.1 |
Estos datos explican la adopción mucho mejor que cualquier relato de revancha. Las grandes tecnológicas no adoptan un lenguaje por simpatía hacia una comunidad. Lo hacen cuando el coste de no cambiar empieza a ser mayor que el coste de aprender algo nuevo.
El choque cultural: “reescríbelo en Rust”
Rust también se ganó enemigos. Parte de su comunidad fue percibida durante años como demasiado evangelizadora. La frase “rewrite it in Rust” se convirtió en meme porque aparecía en debates de casi cualquier proyecto: si algo fallaba, alguien sugería reescribirlo en Rust. Para muchos desarrolladores de C y C++, aquello sonaba arrogante, simplista o directamente ofensivo.
El lenguaje tampoco ayudaba a una adopción suave. Rust exige desaprender algunos hábitos. Un programador acostumbrado a C++ puede sentir que el compilador le discute cada decisión. El borrow checker no negocia: si no puede demostrar que una referencia es válida, el programa no compila. Esa dureza inicial genera rechazo, pero también explica por qué tantos desarrolladores dicen después que el compilador les obliga a pensar mejor.
| Crítica habitual a Rust | Respuesta técnica |
| Es difícil de aprender | Cambia el modelo mental sobre memoria y propiedad |
| La comunidad es intensa | El entusiasmo ha sido a veces contraproducente |
| Compilar es frustrante | El compilador detecta errores antes de producción |
| No todo puede reescribirse | La adopción real suele ser gradual e incremental |
unsafe existe | Reduce la superficie que requiere auditoría estricta |
| C y C++ siguen siendo más maduros | Rust gana terreno en nuevo código y módulos críticos |
La tensión no es solo técnica. C lleva más de 50 años en el centro de la informática. C++ domina grandes bases de código empresariales, videojuegos, navegadores, sistemas embebidos y software de alto rendimiento. Proponer Rust en esos espacios no es sugerir una herramienta nueva, sino cuestionar décadas de experiencia acumulada.
Linux: entrar en la catedral escrita en C
La batalla más simbólica ha sido Linux. El kernel es uno de los proyectos de software más importantes del mundo, escrito históricamente en C y ensamblador, mantenido por una comunidad con una cultura técnica exigente y una memoria larga. Introducir Rust ahí no podía ser sencillo.
El soporte inicial de Rust llegó al kernel Linux 6.1. No significó que Linux pasara a reescribirse en Rust, sino que el lenguaje podía empezar a usarse para determinadas partes, especialmente drivers y nuevos componentes. La idea era prudente: no sustituir millones de líneas de C, sino permitir que nuevo código pueda beneficiarse de garantías de seguridad de memoria.
La resistencia fue real. Algunos mantenedores veteranos no querían aprender Rust ni asumir mantenimiento de código escrito en un lenguaje que no dominaban. Desde su punto de vista, el problema no era solo el lenguaje, sino la carga de mantenimiento a largo plazo: si un subsistema tiene código en C y Rust, ¿quién lo revisa?, ¿quién lo arregla a las tres de la mañana?, ¿qué ocurre cuando una abstracción falla?
Ese debate sigue siendo legítimo. Rust aporta seguridad, pero también complejidad organizativa. La industria no puede resolverlo con consignas. Necesita documentación, herramientas, formación, límites claros para unsafe, interoperabilidad con C y una comunidad capaz de mantener el código durante décadas.
Microsoft y Google: la seguridad como argumento definitivo
Microsoft ha sido una de las empresas que más abiertamente ha defendido el giro hacia lenguajes seguros en memoria. Mark Russinovich, CTO de Azure, recomendó públicamente en 2022 dejar de usar C y C++ para nuevos proyectos cuando sea posible y adoptar Rust u otros lenguajes seguros. La compañía ha empezado a introducir Rust en componentes de Windows y en proyectos de infraestructura cloud, aunque conviene evitar titulares exagerados: Windows no se está reescribiendo entero en Rust.
La estrategia real es más incremental y más creíble. Microsoft está usando Rust en partes nuevas o especialmente problemáticas, allí donde los errores de memoria han sido históricamente caros. Algunos componentes relacionados con gráficos, fuentes, drivers, virtualización o librerías internas son candidatos naturales porque combinan bajo nivel, superficie de ataque y necesidad de rendimiento.
Google ha seguido una estrategia parecida en Android. Su objetivo declarado no es reescribir todo el código C/C++ existente, sino escribir nuevo código nativo en Rust cuando sea adecuado. En Android 13, Google ya hablaba de alrededor de 1,5 millones de líneas de Rust en AOSP y destacaba componentes como Keystore2, Ultra-wideband, DNS-over-HTTP/3 y Android Virtualization Framework. En publicaciones posteriores, la compañía vinculó esa transición con una reducción clara de vulnerabilidades de memoria.
| Empresa / proyecto | Enfoque con Rust |
| Microsoft | Uso gradual en componentes de Windows, Azure y software de sistema |
| Google Android | Nuevo código nativo en Rust como alternativa a C/C++ |
| Linux | Soporte para Rust en drivers y componentes nuevos |
| AWS | Uso de Rust en infraestructura y apoyo a la fundación |
| Mozilla | Origen e incubación del lenguaje |
| NSA / CISA | Recomendación de lenguajes seguros en memoria cuando sea viable |
La diferencia entre reescribirlo todo y cambiar el lenguaje por defecto en nuevo código es enorme. La primera opción suele ser inviable. La segunda puede transformar una base de código con el tiempo, porque las vulnerabilidades de memoria aparecen con más frecuencia en código nuevo o modificado recientemente. Si el nuevo código deja de introducir esa clase de fallos, la curva empieza a bajar.
Por qué Rust no destrona a C de un día para otro
El entusiasmo por Rust puede llevar a una conclusión equivocada: que C y C++ están acabados. No lo están. Siguen siendo esenciales en sistemas operativos, compiladores, motores gráficos, firmware, videojuegos, bases de datos, telecomunicaciones y software industrial. Hay cantidades gigantescas de código probado, optimizado y mantenido durante décadas que no se va a reemplazar de golpe.
Además, Rust no es la única respuesta. Go, Swift, Java, C#, Python y otros lenguajes seguros en memoria cumplen papeles distintos. En sistemas de bajo nivel, Rust destaca porque ofrece control, rendimiento y ausencia de recolector de basura obligatorio, pero no siempre es la opción más adecuada.
| Dónde Rust encaja bien | Dónde el cambio es más difícil |
| Nuevo código de sistema | Bases heredadas enormes en C/C++ |
| Drivers nuevos | Software con certificaciones antiguas |
| Componentes expuestos a ataques | Sistemas con toolchains muy cerradas |
| Infraestructura cloud | Equipos sin experiencia en Rust |
| CLI y servicios de alto rendimiento | Código donde unsafe sería muy amplio |
| Firmware y embebidos modernos | Hardware y SDKs ligados a C |
El futuro más probable no es un mundo sin C, sino un mundo donde C deje de ser la elección automática para nuevo código crítico. Rust no necesita borrar el pasado para ganar. Le basta con ocupar el futuro donde la seguridad de memoria sea un requisito de diseño.
La verdadera victoria: cambiar la pregunta
Hace diez años, la pregunta era si Rust estaba listo para producción. Hoy la pregunta es distinta: por qué escribir nuevo código crítico en C o C++ si existe una alternativa que evita muchas de sus vulnerabilidades históricas. Ese cambio de marco es la verdadera victoria de Rust.
La industria ha pasado de tratar la seguridad de memoria como un problema inevitable a considerarla una decisión de arquitectura. Si un producto nuevo se escribe en un lenguaje inseguro, cada vez será más necesario justificarlo. No por dogma, sino por riesgo, coste de mantenimiento, responsabilidad legal y presión regulatoria.
Rust no “humilló” a C y C++. Los obligó a compartir el centro del escenario. También obligó a empresas gigantes a reconocer que parte de su deuda técnica no se arregla solo con más tests, más parches o más auditorías. A veces hay que cambiar la herramienta.
La historia empezó con un desarrollador frustrado por un ascensor roto y pasó por despidos, memes, resistencia y discusiones en conferencias. Pero su desenlace provisional es mucho más serio: Rust está en la conversación de Windows, Android, Linux, cloud, seguridad nacional y software crítico.
No es la venganza de unos programadores despedidos. Es la factura técnica de 50 años de memoria gestionada a mano. Y por primera vez en mucho tiempo, la industria parece dispuesta a pagarla cambiando de lenguaje, poco a poco, donde más duele.
Preguntas frecuentes
¿Qué es Rust?
Rust es un lenguaje de programación de sistemas diseñado para ofrecer rendimiento similar al de C y C++, pero con garantías de seguridad de memoria y concurrencia controladas por el compilador.
¿Quién creó Rust?
Rust fue iniciado por Graydon Hoare en 2006 como proyecto personal mientras trabajaba en Mozilla. Mozilla empezó a patrocinar oficialmente su desarrollo en 2009.
¿Mozilla abandonó Rust en 2020?
Mozilla realizó despidos masivos en 2020 que afectaron a equipos vinculados a Rust, Servo y otros proyectos. Rust no desapareció: en 2021 se creó la Rust Foundation con apoyo de AWS, Google, Huawei, Microsoft y Mozilla.
¿Por qué Microsoft y Google usan Rust?
Porque muchos fallos graves de seguridad proceden de errores de memoria en C y C++. Rust permite escribir código de bajo nivel reduciendo esa clase de vulnerabilidades, especialmente en componentes nuevos o sensibles.
¿Rust sustituirá por completo a C y C++?
No a corto plazo. C y C++ seguirán siendo fundamentales durante años. Lo que está cambiando es que Rust gana peso en nuevo código crítico, drivers, infraestructura cloud y componentes donde la seguridad de memoria es prioritaria.
