Durante décadas, C ha sido el lenguaje del kernel, los drivers y los sistemas embebidos. Su eficiencia y control sobre el hardware son difíciles de igualar. Pero esa misma cercanía al metal tiene un coste conocido por cualquiera que haya depurado un sistema a las 3 de la mañana: la gestión manual de memoria produce errores que son caros, difíciles de reproducir y, en sistemas críticos, potencialmente devastadores.
Rust lleva años siendo el «lenguaje prometedor» que aparecía en encuestas de Stack Overflow y en charlas de conferencias. Pero hay un momento en que las promesas se convierten en producción. Ese momento, para Rust en sistemas, ya ha llegado. Y conviene entender exactamente qué ha pasado, qué significa en la práctica, y también qué limitaciones reales tiene.
Por qué el problema de memoria en C no es solo «programar mejor»
Antes de hablar de Rust hay que entender por qué el problema es estructural y no de disciplina individual.
Microsoft y Google han reportado de forma independiente que más del 70% de sus vulnerabilidades críticas históricas vienen de errores de memoria: buffer overflows, use-after-free, null pointer dereferences, race conditions. No es un problema de programadores descuidados. Es un problema de que C y C++ dan al programador un bisturí sin protecciones y esperan que nunca se corte.
Los equipos técnicos han desarrollado herramientas para detectar estos fallos: sanitizers, fuzzers, análisis estático, revisiones exhaustivas. Todo eso ayuda, pero actúa sobre síntomas. La causa raíz sigue siendo el código.
El planteamiento de Rust es distinto: que el compilador rechace el código que podría producir esos errores, antes de que llegue a producción. No como un linter que da avisos, sino como una garantía en tiempo de compilación. Si el código compila, cierta clase de bugs simplemente no puede existir.
Los datos reales de Google en Android
Google es quien tiene los números más contundentes y mejor documentados sobre esto.
En 2019, el 76% de las vulnerabilidades de seguridad en Android eran de memoria. En 2024, ese porcentaje bajó al 24%, muy por debajo del 70% que sigue siendo la norma en la industria. En términos absolutos: de 223 vulnerabilidades de memoria en 2019 a menos de 50 en 2024. En 2025, por primera vez, han bajado del 20%.
La densidad de vulnerabilidades en código Rust de Android está siendo de 0,2 por millón de líneas. En C/C++ histórico es de alrededor de 1.000 por millón de líneas. Eso es una diferencia de tres órdenes de magnitud.
Pero hay un dato que no suele mencionarse y que es igual de interesante: los cambios en Rust tienen una tasa de rollback cuatro veces menor que los de C++, y pasan un 25% menos de tiempo en revisión de código. Google lo resume con una frase que tiene peso: «el camino más seguro es ahora también el más rápido».
Eso es relevante porque el argumento habitual contra Rust es que ralentiza el desarrollo. Los datos de Android dicen lo contrario, al menos a escala y con el tiempo suficiente para que el equipo domine el lenguaje.
Microsoft: del experimento al kernel en producción
Microsoft tiene uno de los historiales más extensos de vulnerabilidades relacionadas con memoria en Windows, particularmente en componentes como Win32k.sys, el subsistema gráfico que lleva años generando escaladas de privilegios de forma consistente. El Azure CTO Mark Russinovich lo describió en RustConf 2025 como «un depósito de petróleo subterráneo que gotea constantemente, gota a gota».
La respuesta no ha sido solo un proyecto de investigación. Hay código Rust en producción en Windows hoy:
- win32kbase_rs.sys: un componente real del kernel de Windows escrito en Rust, ya desplegado.
- Hyper-V: Microsoft ha confirmado que Rust forma parte de componentes en producción del hipervisor.
- OpenVMM: el Virtual Machine Manager que corre bajo las VMs de Azure está escrito en Rust desde cero.
- DirectWrite: 152.000 líneas reescritas en Rust.
- Kernel de Windows: 36.000 líneas migradas a Rust.
El proyecto en GitHub relevante hoy es windows-drivers-rs, el framework para escribir drivers de Windows en Rust, que el equipo de drivers de Microsoft mantiene activamente. El equipo de WDF (Windows Driver Framework) está diseñando abstracciones seguras en Rust para que los desarrolladores de drivers puedan escribir código más idiomático y seguro.
Vale la pena mencionar un detalle honesto: en 2025, investigadores de Check Point encontraron la primera vulnerabilidad documentada en un componente Rust del kernel de Windows, precisamente en win32kbase_rs.sys. Era un acceso fuera de límites al procesar metaarchivos EMF malformados que causaba BSOD. La propia naturaleza del fallo es interesante: Rust lo detectó correctamente y crasheó de forma controlada en lugar de permitir corrupción de memoria silenciosa. Aun así, la vulnerabilidad existía. Rust no es impenetrable, reduce drásticamente cierta clase de bugs, no los elimina todos.
Linux: del experimento a «Rust se queda»
Esta es la historia con más drama técnico y más relevancia para cualquiera que trabaje con Linux.
El soporte para Rust entró en el kernel en la versión 6.1, en 2022, marcado explícitamente como «experimental». Lo que significa que la comunidad se reservaba el derecho de echarlo atrás si no funcionaba.
El camino no fue tranquilo. En agosto de 2024, Wedson Almeida Filho, uno de los principales mantenedores del proyecto Rust for Linux e ingeniero de Microsoft, anunció su dimisión en la lista de correo del kernel citando «nontechnical nonsense»: resistencia no técnica de parte de mantenedores veteranos que no querían aprender Rust ni quería que su código C tuviera dependencias con bindings de Rust. Ted Ts’o, mantenedor del sistema de ficheros ext4, fue uno de los que expresó públicamente su reticencia. El debate llegó a tener, según las propias palabras de Linus Torvalds en el Open Source Summit 2024, «visos de guerra religiosa».
Pero en diciembre de 2025, en el Kernel Maintainers Summit de Tokio, el consenso fue unánime: el experimento terminó. Rust forma parte del kernel y no se va. El mantenedor del proyecto Miguel Ojeda lo formalizó eliminando la sección «The Rust experiment» de la documentación. Greg Kroah-Hartman, mantenedor del kernel estable, confirmó que los drivers en Rust están demostrando ser más seguros que los de C, y que los problemas de interacción entre código Rust y el core en C habían sido menores de lo esperado.
Hay datos concretos de hasta dónde ha llegado la integración:
- Android 16 corre el asignador de memoria ashmem (anonymous shared memory) escrito en Rust sobre el kernel 6.12. Millones de dispositivos ya ejecutan Rust en producción vía Android.
- El subsistema DRM (gestión de gráficos del kernel) está a un año de requerir Rust para drivers nuevos y prohibir C en ese contexto.
- Debian ha anunciado dependencias duras de Rust en APT a partir de mayo de 2026.
- En abril de 2025, el kernel tenía aproximadamente 34 millones de líneas de C y 25.000 de Rust. La proporción es pequeña, pero la tendencia es clara y la velocidad de adopción está acelerando.
La documentación oficial del kernel sobre Rust está en https://docs.kernel.org/rust/ y el proyecto en https://rust-for-linux.com/.
El modelo de propiedad de Rust: qué resuelve y qué no
Para entender por qué Rust previene ciertos errores, hay que entender brevemente su mecanismo central.
Rust gestiona la memoria mediante un sistema de ownership (propiedad) y borrowing (préstamos) que el compilador verifica en tiempo de compilación, sin garbage collector y sin overhead en runtime:
- Cada valor tiene un único propietario en un momento dado.
- Se puede prestar una referencia (inmutable o mutable), pero no puedes tener una referencia mutable y otra cualquiera al mismo tiempo.
- Cuando el propietario sale de scope, la memoria se libera automáticamente.
Esto elimina en origen los use-after-free (referenciar memoria ya liberada), los double-free, y ciertos tipos de data races en código concurrente. El compilador simplemente no permite compilar código que violaría esas reglas.
Lo que Rust no elimina: errores lógicos, vulnerabilidades en código marcado como unsafe, integer overflows en ciertos contextos, y bugs de diseño de más alto nivel. El bloque unsafe existe en Rust porque hay operaciones que necesariamente requieren gestión manual (FFI con C, ciertos accesos a hardware), y en esos contextos las garantías del compilador no aplican. Alrededor del 27% de los bugs en la base de datos RustSec provienen del uso incorrecto de unsafe. No es un lenguaje mágico, es un lenguaje con mejores herramientas para evitar una clase específica y muy frecuente de errores.
Cuándo tiene sentido considerar Rust en sistemas
No hay que reescribir nada por seguir una tendencia. El criterio tiene que ser técnico:
Casos donde Rust aporta valor real:
- Código nuevo en componentes donde los errores de memoria tienen consecuencias graves: drivers, parsers de formatos externos, código de red, criptografía.
- Proyectos donde el coste de depurar bugs de memoria es alto y recurrente.
- Código concurrente complejo donde los data races son un problema histórico.
Casos donde probablemente no merece el esfuerzo inmediato:
- Código C estable, bien probado y sin historial de vulnerabilidades de memoria.
- Equipos sin tiempo para absorber la curva de aprendizaje real (que es considerable: el borrow checker tiene una lógica propia que lleva tiempo interiorizar).
- Partes del sistema donde el rendimiento extremo ya está optimizado en C y no hay problemas de seguridad asociados.
La convivencia con C es posible mediante FFI y es la estrategia que tanto el kernel Linux como Microsoft están usando: adopción gradual en componentes nuevos o en reescrituras justificadas, no migración masiva forzada.
El estado del ecosistema en 2025-2026
Rust lleva diez años consecutivos siendo el lenguaje «más querido» en la encuesta de Stack Overflow. En 2025, su uso en programación de sistemas creció un 40% respecto al año anterior. Google invirtió 1 millón de dólares en la Rust Foundation para mejorar la interoperabilidad entre C++ y Rust. La NSA y CISA llevan años recomendando oficialmente la migración a lenguajes memory-safe. DARPA tiene un proyecto activo para usar IA en la traducción de código C a Rust.
No es una burbuja de hype. Es una respuesta sostenida de la industria a un problema real y medido.
Para seguir aprendiendo
«The Rust Programming Language», Steve Klabnik y Carol Nichols (No Starch Press, 2023). El libro oficial, disponible también gratuitamente en https://doc.rust-lang.org/book/. Es el punto de partida obligatorio.
«Programming Rust», Jim Blandy y Jason Orendorff (O’Reilly, 2ª edición, 2021). Más orientado a sistemas y con mayor profundidad técnica que el libro oficial. Recomendable una vez superada la curva inicial.
Rust for Linux — Sitio oficial del proyecto: https://rust-for-linux.com/. Incluye documentación, política del kernel sobre Rust y el estado actual de la integración.
Documentación oficial del kernel Linux sobre Rust: https://docs.kernel.org/rust/. Referencia directa para quien quiera entender cómo se usa Rust dentro del kernel.
«Safe Coding» — Google Security Blog: El informe de Google sobre la reducción de vulnerabilidades en Android está en https://security.googleblog.com buscando «Rust in Android move fast fix things». Datos primarios, sin intermediarios.
windows-drivers-rs — Repositorio oficial de Microsoft para drivers en Rust: https://github.com/microsoft/windows-drivers-rs. Con documentación y ejemplos reales.
«Operating Systems: Three Easy Pieces», Remzi H. y Andrea C. Arpaci-Dusseau (disponible gratis en https://pages.cs.wisc.edu/~remzi/OSTEP/). Para quien quiera el contexto de sistemas operativos que hace que todo esto tenga sentido técnico.