Rust en el kernel Linux: balance tras varios años
Actualizado: 2026-07-07
La decisión de aceptar Rust en el kernel Linux se tomó en 2022 y entró en Linux 6.1[1] a mediados de diciembre de ese año, como ya conté en el primer balance de esta serie. En aquel momento la infraestructura era mínima, los bindings cubrían poca superficie y la mayoría del debate giraba en torno a si la inclusión era deseable o no. Hoy, en 2026, con drivers reales en producción, con un subconjunto cada vez mayor del kernel expuesto a Rust y tras varios episodios públicos de fricción entre desarrolladores de Rust y mantenedores tradicionales, toca hacer balance técnico. No de hype ni de revolución: de qué funciona, qué sigue doliendo y hacia dónde razonablemente va la cosa.
Puntos clave
-
Los drivers en Rust en producción (GPU de Apple en Asahi Linux, módulos NVMe experimentales) demuestran viabilidad en componentes de complejidad real.
-
La reducción de bugs de memoria es el beneficio más tangible: use-after-free, carreras de concurrencia sobre lock mal razonado, simplemente no se dan con la misma frecuencia.
-
El coste cultural es real: fricción entre la filosofía Rust (tipos ricos, abstracciones) y la filosofía kernel (estabilidad, evitar capas). La dimisión de un mantenedor de Rust en agosto de 2024 fue sintomática.
-
Los bindings incompletos siguen siendo el limitador práctico: zonas enteras del kernel sin interfaz Rust adecuada.
-
Rust en el kernel es la mejor puerta de entrada disponible para nuevos contribuidores que vienen del ecosistema Rust.
El punto de partida y el progreso real
Lo que se decidió en 2022 fue que Rust entraría como ciudadano de segunda clase al principio: no se permitiría reescribir código existente en Rust, solo añadir subsistemas nuevos. La idea era no tocar lo que funciona y dejar que la experiencia se acumulase en zonas donde añadir un lenguaje diferente tuviera contrapartida clara: memoria segura, razonamiento sobre concurrencia más riguroso y reducción de clases enteras de bugs.
El progreso en los primeros dos años fue modesto. En 2024, el driver Apple GPU del proyecto Asahi (escrito en Rust desde que su desarrollador principal empezó a portarlo, en agosto de 2022) demostró que era posible hacer un componente de complejidad real sin reescribir el subsistema DRM completo. Según el propio relato del proyecto[2], semanas después de arrancar el port ya renderizaba un cubo en pantalla, y poco después corría una sesión completa de GNOME sin las carreras de memoria típicas de un driver de kernel recién escrito: solo aparecieron un puñado de bugs de lógica y un problema puntual en la gestión de memoria. A partir de ahí, el ritmo de contribución subió.
En 2026, los drivers relevantes escritos en Rust incluyen:
-
El driver Apple GPU, en uso diario por decenas de miles de desarrolladores en Macs con Asahi Linux.
-
Un driver NVMe experimental[3], mantenido por Andreas Hindborg en Samsung, que demuestra viabilidad en zona caliente del kernel: en las comparativas contra 6.8-6.15 rinde igual que el driver en C en la mayoría de cargas, aunque en bloques de 512 bytes el C sigue ganando hasta un 6 % por el coste de cómputo adicional.
-
Varios drivers de virtualización y utilidades pequeñas.
El volumen total sigue siendo pequeño comparado con los millones de líneas de C del kernel, pero la trayectoria está clara y el código producido es robusto.
Qué ha funcionado bien
Reducción efectiva de bugs. El tipo de errores de memoria que plagan el C del kernel (punteros sueltos, use-after-free, carreras de concurrencia sobre lock mal razonado) simplemente no se dan en Rust con la misma frecuencia porque el compilador los detecta. El coste inicial de escribir código más verboso con tipos explícitos se amortiza enseguida en estabilidad de driver, sobre todo en código que maneja memoria DMA y concurrencia a través de interrupciones.
El modelo de unsafe ha funcionado mejor de lo que algunos temían. Las zonas de interfaz con C están marcadas explícitamente, la superficie insegura está acotada y el resto del código aprovecha las garantías de memoria del lenguaje. En la práctica, revisar un parche Rust del kernel se parece bastante a revisar un parche C, pero la confianza en que las partes seguras son efectivamente seguras reduce carga cognitiva.
Barrera de entrada menor para nuevos contribuidores. El kernel Linux siempre tuvo fama de comunidad hostil y con curva de aprendizaje brutal. Rust no resuelve eso completamente, pero sí baja la primera barrera técnica: gente que nunca tocó el kernel en C se anima con Rust porque el lenguaje les resulta familiar y las garantías del compilador les dan seguridad de no introducir bugs catastróficos en su primer parche.
Qué sigue costando
La fricción cultural interproceso. La filosofía del kernel Linux prima compatibilidad hacia atrás, estabilidad y evitar capas innecesarias. La cultura Rust prefiere tipos ricos, abstracciones sobre APIs de bajo nivel y refactors para limpiar códigos antiguos. Estos instintos chocan con frecuencia.
El caso más citado es la dimisión pública de Wedson Almeida Filho[4] el 28 de agosto de 2024, tras casi cuatro años como mantenedor de Rust for Linux. Señaló como detonante un choque con Ted Ts’o sobre cómo tipar en Rust la semántica de un sistema de ficheros, y quedó para el recuerdo la respuesta que le dio Ts’o en la lista de correo del kernel: «here’s the thing, you’re not going to force all of us to learn Rust». No fue un conflicto técnico puro sino cultural: expectativas diferentes sobre cómo revisar código, negociar cambios y manejar puntos de fricción. Este episodio se ha repetido con menor intensidad en otros hilos y forma parte del coste cultural real de integrar un paradigma nuevo en un proyecto con décadas de tradición.
Bindings incompletos. Hay zonas enteras del kernel donde no existe interfaz Rust adecuada, como ya se veía en los primeros drivers estables, y añadirla requiere trabajo significativo de alguien que conozca bien C del kernel y Rust del ecosistema. Este trabajo no es glamouroso, no produce features visibles y tiende a caer sobre un número muy pequeño de personas.
Tooling. La cadena de compilación Rust en el kernel depende de versiones específicas del compilador y produce dependencias de build complejas. Mantenedores tradicionales no siempre quieren lidiar con esto, especialmente en distribuciones antiguas o entornos de build. La situación ha mejorado mucho desde 2022 pero no es trivial.
Hacia dónde va
La siguiente fase, ya visible en 2026, es la aceptación de Rust para subsistemas grandes en áreas donde la seguridad de memoria compensa el coste cultural:
-
Filesystems nuevos.
-
Drivers de red con alta concurrencia.
-
Subsistemas de gestión de memoria experimentales donde el razonamiento sobre ownership aporta valor claro.
No se espera reescribir el kernel en Rust, eso está fuera de toda discusión realista, pero sí que zonas nuevas se escriban directamente en Rust cuando aporta valor.
Y hay una noticia reciente que cambia el marco de esta sección: Linux 7.0, publicado en abril de 2026[5], cierra formalmente el periodo experimental de Rust en el kernel. El lenguaje deja de ser un añadido tolerado y pasa a tener soporte de primer nivel junto a C, algo que se venía negociando desde la cumbre de mantenedores del kernel de 2025. En la práctica esto no cambia el código de la noche a la mañana, pero sí la conversación: ya no toca justificar por qué existe Rust en el kernel, sino cómo se extiende.
El otro vector es la maduración del ecosistema de herramientas: documentación adecuada, procesos de revisión más claros y convivencia con mantenedores más profesionalizada. Las nuevas contribuciones llegan mejor preparadas, con más disposición a adaptar el estilo al de la comunidad kernel.
Para quien quiera entrar ahora, Rust en el kernel es probablemente la mejor puerta de entrada disponible: ecosistema maduro, documentación razonable, mentores activos. El balance de Rust para backend en producción da perspectiva complementaria sobre cómo el lenguaje funciona fuera del kernel en contextos comerciales.
Conclusión
Tras cuatro años y medio de Rust en el kernel Linux, el balance técnico es claramente positivo, el balance cultural es incómodo pero en mejora y el camino hacia delante está razonablemente marcado. La apuesta ha funcionado lo suficiente para justificar mantenerla y suficientemente poco para evitar triunfalismo.
La lección general para quien sigue el proyecto de fuera: integrar un paradigma técnico nuevo en una comunidad grande con tradición propia es mucho más difícil que escribir el código. El código es la parte fácil. La parte difícil es negociar cultura, convencer a gente con razones fundadas que prefiere otra cosa y aguantar las primeras rondas de conflicto hasta que se establecen normas estables. Rust en Linux ha pasado esas rondas y ha sobrevivido, lo cual es en sí mismo un indicador fuerte de que va a quedarse. La pregunta ya no es si Rust es viable en el kernel, sino hasta dónde va a llegar en los próximos años.
Este artículo también está disponible en inglés.
Última revisión: 2026-04-22.
