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.
El punto de partida y el progreso real
Lo que efectivamente se decidió en 2022 es 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 complejidad con otro lenguaje 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. Rust estaba disponible en el árbol pero pocos drivers lo usaban y los bindings cubrían poca parte del kernel. En 2024 la cosa empezó a cambiar con el driver Apple GPU del proyecto Asahi, escrito completamente en Rust, que 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 Apple GPU en uso diario por decenas de miles de desarrolladores en Macs con Asahi Linux, un driver de NVMe experimental que demuestra viabilidad en zona caliente, varios drivers de virtualización y una serie de 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
El primer punto positivo sólido es la reducción efectiva de bugs en los drivers escritos en Rust. El tipo de errores de memoria que plagan 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 y 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 segundo punto es que el modelo de unsafe en Rust ha funcionado mejor de lo que algunos temían. Las zonas de interfaz con C están marcadas explícitamente, la superficie inseguro 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.
El tercer punto positivo es que los desarrolladores jóvenes que vienen del mundo Rust entran al kernel con una barrera cognitiva menor que antes. El kernel Linux siempre tuvo fama de comunidad hostil para recién llegados 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 compiler-checked les dan seguridad de no introducir bugs catastróficos en su primer parche.
Qué sigue costando
El coste principal en 2026 sigue siendo la fricción interproceso entre cultura Rust y cultura kernel tradicional. 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 y producen conflictos visibles cuando un parche Rust propone cambiar una API existente o cuando un mantenedor senior rechaza un parche por razones que desarrolladores Rust perciben arbitrarias.
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. Estos episodios se han repetido, aunque con menos intensidad, y forman parte del coste cultural real de integrar un paradigma nuevo en un proyecto con décadas de tradición.
El segundo coste es que los bindings siguen siendo incompletos. Hay zonas enteras del kernel donde no existe interfaz Rust adecuado 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.
Hacia dónde va
La siguiente fase, que ya se nota 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. Rust-for-Linux ha establecido documentación adecuada, los procesos de revisión están más claros y la convivencia con mantenedores se ha profesionalizado. Los conflictos de 2024 y 2025 sirvieron como aprendizaje cultural y las nuevas contribuciones llegan mejor preparadas, con más disposición a adaptar el estilo al de la comunidad kernel.
Para desarrolladores que quieran entrar ahora, Rust en el kernel es probablemente la mejor puerta de entrada disponible. El ecosistema está maduro, la documentación es razonable, hay mentores activos y el tipo de bugs que solían intimidar a recién llegados quedan cubiertos por el compilador. Comparado con empezar directamente en C del kernel con veinte años de convenciones implícitas, el camino Rust es claramente menos hostil.
Mi lectura
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. En 2026, Rust no domina el kernel ni va a dominarlo en los próximos años; lo que sí va a hacer es ocupar progresivamente nichos donde aporta valor claro y desde ahí expandirse.
Para quien sigue el proyecto de fuera, la lección general es que 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.
