Rust en el kernel Linux: balance tras varios años

Actualizado: 2026-05-03

La decisión de aceptar Rust en el kernel Linux se tomó en 2022 y entró en Linux 6.1 a finales de ese año. 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, sino de qué funciona, qué sigue doliendo y hacia dónde razonablemente va la cosa.

Puntos clave

• Los drivers en Rust en producción —Apple GPU 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). El episodio de febrero de 2025 fue sintomático.
• 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 completamente en Rust— demostró que era posible hacer un componente de complejidad real sin reescribir el subsistema DRM completo. 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 que demuestra viabilidad en zona caliente del kernel.
• 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 episodio de febrero de 2025 con la dimisión pública de un mantenedor de Rust tras fricciones con mantenedores de C fue sintomático. 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. Estos episodios se han repetido con menor intensidad y forman 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 y añadirlo 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.

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 en empresa da perspectiva complementaria sobre cómo el lenguaje funciona fuera del kernel en contextos de producción 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.

Última revisión: 2026-04-22.