La discusión sobre Rust en el kernel Linux ya no va de si el lenguaje puede entrar. Eso ocurrió hace tiempo. La pregunta real es mucho más incómoda para una parte de la comunidad: hasta dónde debe llegar, quién decide los límites y cómo se integra una tecnología nueva en un proyecto que lleva más de tres décadas construido alrededor de C, cultura C y mantenedores formados en C.
El debate se ha presentado muchas veces como una guerra civil entre dos bandos: los defensores del C clásico y los partidarios de Rust como lenguaje más seguro para sistemas. La imagen tiene algo de verdad, porque las tensiones son reales y han provocado salidas de desarrolladores relevantes. Pero también simplifica demasiado. Linux no va a reescribirse entero en Rust, ni C va a desaparecer del kernel. Lo que está ocurriendo es más lento, más técnico y más difícil: Rust está dejando de ser una rareza experimental para convertirse en una opción legítima en partes nuevas del kernel, sobre todo drivers y componentes donde la seguridad de memoria puede evitar clases enteras de errores.
Linus Torvalds no ha declarado la derrota de C. Pero sí ha dejado claro que Rust ya forma parte del debate normal del kernel y que un mantenedor de una API en C no debería bloquear automáticamente código Rust que la usa desde otra parte del árbol si no modifica directamente su subsistema. Esa posición cambia el equilibrio político del proyecto. Rust ya no es solo una prueba tolerada desde fuera; es una herramienta que algunos desarrolladores quieren usar dentro de Linux.
El problema no es C, es la memoria insegura
C sigue siendo uno de los lenguajes más importantes de la historia de la informática. Es rápido, directo, pequeño, predecible y muy cercano al hardware. El kernel Linux existe como lo conocemos porque C permite controlar memoria, estructuras de datos, llamadas de bajo nivel, interrupciones, drivers y arquitecturas con una flexibilidad difícil de igualar.
Pero esa libertad tiene un precio. Errores como use-after-free, buffer overflows, double free, accesos fuera de límites o punteros colgantes llevan décadas detrás de algunas de las vulnerabilidades más graves en sistemas escritos en C y C++. No porque los desarrolladores sean malos, sino porque incluso los mejores cometen errores cuando trabajan con código complejo, concurrencia, entradas no confiables y millones de líneas acumuladas durante años.
Rust intenta atacar justo esa clase de fallos. Su sistema de ownership, borrow checker y reglas de concurrencia impiden en compilación muchos errores de memoria que en C solo se detectan con revisiones, pruebas, sanitizers o suerte. En el kernel, donde un fallo puede terminar en escalada de privilegios, corrupción de memoria o caída del sistema, esa diferencia importa.
| Lenguaje | Fortaleza principal | Riesgo principal |
|---|---|---|
| C | Control fino, simplicidad, rendimiento y enorme base instalada | Gestión manual de memoria y errores difíciles de detectar |
| C++ | Abstracciones potentes y rendimiento en sistemas complejos | Complejidad, compatibilidad y riesgos de memoria si se usa mal |
| Rust | Seguridad de memoria y concurrencia con coste bajo en tiempo de ejecución | Curva de aprendizaje, integración con C y complejidad de diseño |
| Unsafe Rust | Permite operaciones de bajo nivel necesarias en sistemas | Reduce parte de las garantías si se usa sin disciplina |
Por eso no es exacto decir que Rust sustituye a C por ser más rápido. Rust no es mágicamente más rápido que C. En código de bajo nivel muy ajustado, C puede seguir siendo igual o más eficiente, y en entornos extremos como trading de baja latencia o parsers muy especializados, algunos equipos solo alcanzan paridad con Rust cuando eliminan biblioteca estándar, reducen abstracciones y usan instrucciones específicas.
La ventaja de Rust no es prometer más rendimiento en todos los casos. Es reducir una categoría enorme de errores sin renunciar al rendimiento necesario para sistemas.
Linux no se puede reescribir, pero sí puede cambiar por capas
Pensar en un kernel Linux reescrito en Rust es una fantasía poco útil. Linux contiene décadas de trabajo, soporte para multitud de arquitecturas, miles de drivers, subsistemas maduros y una cultura de revisión muy exigente. Reescribirlo completo sería caro, arriesgado y probablemente peor que mantenerlo.
El camino realista es otro: escribir código nuevo en Rust donde tenga sentido, crear bindings seguros hacia APIs existentes en C, empezar por drivers, probar patrones de integración y aprender dónde Rust aporta valor sin romper el modelo de desarrollo del kernel.
Eso explica por qué el avance parece lento. No basta con aceptar el lenguaje. Hay que resolver interoperabilidad, herramientas, compiladores, documentación, estilos de revisión, ownership de APIs, integración con Kbuild, soporte por arquitecturas y límites claros para unsafe. También hay que convencer a mantenedores que no quieren tener que entender Rust para revisar indirectamente cambios que afectan a sus APIs.
| Área del kernel | Encaje potencial de Rust |
| Drivers nuevos | Alto, porque se puede diseñar desde cero |
| Bindings hacia APIs C | Necesario, pero delicado |
| Subsistemas críticos existentes | Difícil, por riesgo y coste de integración |
| Módulos experimentales | Útiles para validar patrones |
| Código de red o almacenamiento | Interesante, pero exige rendimiento y revisión estricta |
| Reescritura masiva de código C | Poco realista a corto y medio plazo |
Ahí aparece el choque cultural. Para un mantenedor C veterano, Rust puede parecer una capa que complica APIs ya difíciles. Para un desarrollador Rust, la resistencia puede parecer una defensa de inercias antiguas frente a datos claros sobre seguridad de memoria. Ambos lados tienen parte de razón. La integración de Rust no puede imponerse ignorando el mantenimiento real del kernel, pero tampoco puede bloquearse solo porque obliga a aprender nuevas herramientas.
La presión externa empuja hacia lenguajes seguros
El debate interno de Linux no ocurre en el vacío. Gobiernos, empresas y organismos de ciberseguridad llevan años señalando que los fallos de memoria son una fuente recurrente de vulnerabilidades graves. Estados Unidos ha publicado informes recomendando reducir el uso de lenguajes no seguros para memoria en nuevo software crítico cuando sea posible. Google ha defendido una estrategia de prevención basada en Rust para Android, y Microsoft lleva años reconociendo el peso de los errores de memoria en su historial de vulnerabilidades.
Esto no significa que todas las organizaciones vayan a abandonar C o C++ mañana. Mucho software crítico seguirá escrito en esos lenguajes durante décadas. Pero sí cambia el estándar de responsabilidad. Cuando se inicia un componente nuevo, especialmente si procesa entradas no confiables o se ejecuta con privilegios, cada vez será más difícil justificar por qué no se ha considerado un lenguaje seguro para memoria.
Linux, como base de servidores, móviles, routers, nubes, sistemas embebidos y supercomputación, no puede quedarse fuera de esa conversación. Si el mundo empieza a exigir menos errores de memoria en software crítico, el kernel también tendrá que adaptarse.
La salida de mantenedores muestra el coste humano
El avance de Rust en Linux también ha dejado desgaste. Wedson Almeida Filho, uno de los desarrolladores más relevantes de Rust for Linux, dejó el proyecto en 2024 tras casi cuatro años, citando cansancio ante discusiones no técnicas. Hector Martin, conocido por su trabajo en Asahi Linux y Apple Silicon, también acabó alejándose del mantenimiento del kernel tras tensiones vinculadas al proceso de integración y a la gestión comunitaria.
Estas salidas importan porque Linux depende de personas. El kernel no es una máquina abstracta que acepta parches por sí sola. Es una red de mantenedores, revisores, expertos en arquitecturas, responsables de subsistemas y desarrolladores que dedican años a comprender partes muy concretas del sistema. Cuando el debate técnico se convierte en desgaste personal, el proyecto pierde talento.
La integración de Rust no puede medirse solo en líneas de código aceptadas. También hay que medir si el proceso permite que los nuevos contribuidores trabajen sin chocar continuamente con barreras culturales, y si los mantenedores veteranos reciben documentación, herramientas y apoyo suficiente para revisar cambios sin sentirse desplazados.
Rust tampoco elimina todos los problemas
Conviene evitar el entusiasmo ingenuo. Rust reduce muchos errores de memoria, pero no elimina bugs lógicos, problemas de diseño, fallos de autorización, errores criptográficos, malas configuraciones o vulnerabilidades en código unsafe. En sistemas de bajo nivel, Rust necesita a veces interactuar con C, usar FFI, acceder a hardware o recurrir a bloques unsafe. Ese código debe revisarse con tanto cuidado como el C que intenta encapsular.
Además, Rust puede hacer más difícil ciertos refactors si el diseño inicial no encaja bien con sus reglas de propiedad y préstamo. Esa crítica aparece a menudo entre desarrolladores de sistemas: Rust obliga a pensar antes en la estructura de datos, el ciclo de vida y la concurrencia. Eso puede ser una virtud para seguridad, pero también un coste en proyectos donde el diseño cambia muchas veces.
El punto razonable está en asumir Rust como una herramienta potente, no como una religión. Para drivers nuevos, interfaces bien acotadas y componentes expuestos, puede aportar mucho. Para reescrituras masivas o caminos calientes donde cada ciclo importa, la decisión debe tomarse con mediciones reales.
La vieja guardia no ha perdido; ha cambiado el terreno
Decir que los desarrolladores C han perdido la batalla es una forma llamativa de contar la historia, pero no es precisa. C seguirá siendo el centro del kernel Linux durante muchos años. Lo que sí ha cambiado es que C ya no tiene monopolio cultural absoluto sobre el futuro del kernel.
Rust ha entrado porque resuelve un problema real. No todos los problemas, pero sí uno de los más persistentes en software de sistemas: la seguridad de memoria. Y cuando gobiernos, grandes tecnológicas, proyectos móviles y comunidades de seguridad empujan en la misma dirección, la resistencia ya no puede basarse solo en tradición.
El desenlace más probable no será una victoria total de Rust ni una expulsión del C. Será una convivencia incómoda pero productiva. C mantendrá el núcleo histórico, Rust crecerá en zonas nuevas y el proyecto tendrá que definir reglas claras para que ambos mundos no se bloqueen mutuamente.
Linux siempre ha sobrevivido porque ha sabido absorber cambios sin romper su base. Pasó con nuevas arquitecturas, nuevos sistemas de archivos, virtualización, contenedores, eBPF y modelos de seguridad. Rust es otro cambio de esa escala cultural: no sustituye de golpe lo anterior, pero obliga a revisar cómo se escribe el futuro.
La frase más importante quizá no sea que Linus haya escogido un bando. Es que el kernel ya no puede fingir que Rust es una moda externa. La discusión ha entrado en el corazón del proyecto. Y cuando una tecnología entra ahí, deja de ser una promesa para convertirse en mantenimiento, reglas, conflictos y código real.
Preguntas frecuentes
¿Linux va a reescribirse en Rust?
No. El kernel Linux seguirá siendo mayoritariamente C durante mucho tiempo. Rust se está introduciendo de forma gradual, sobre todo para código nuevo, drivers y capas donde la seguridad de memoria puede aportar valor.
¿Rust es más rápido que C?
No necesariamente. Rust puede ofrecer rendimiento comparable en muchos escenarios, pero su principal ventaja no es ser más rápido, sino reducir errores de memoria y concurrencia sin depender de un recolector de basura.
¿Por qué hay tanta resistencia dentro del kernel?
Porque integrar Rust afecta a APIs, revisión de código, herramientas, documentación y responsabilidades de mantenimiento. Algunos mantenedores temen tener que soportar una capa que no dominan.
¿Qué papel ha tenido Linus Torvalds?
Torvalds ha respaldado la presencia de Rust en el kernel de forma gradual y ha intervenido para aclarar que los mantenedores no deberían bloquear automáticamente código Rust que usa APIs existentes sin modificar sus subsistemas.
