La integración de Rust en Linux ha tenido un gran nivel de aceptación por parte de la comunidad y desarrolladores

Una de las grandes problemáticas que han surgido en el desarrollo del Kernel de Linux durante mucho tiempo, es la idea de encontrar un candidato perfecto para cambiar el lenguaje de programación «C» por uno más moderno y hasta hace poco con la llegada de Rust, esta idea no ha dejado de ponerse sobre la mesa.

Con la primera preview de Rust en Linux 6.1, reavivo los ánimos por parte de gran parte de los desarrolladores del Kernel y Jonathan Corbet señala que «todavía no habría suficiente Rust en el núcleo para hacer algo interesante», la inclusión de este lenguaje ha reavivado el debate sobre la necesidad de desechar el lenguaje C en beneficio de Rust en términos de programación del sistema. La pregunta divide a la comunidad de desarrolladores.

Asahi Linya asumió la tarea de desarrollar un controlador de unidad de procesamiento de gráficos (GPU) para Mac M1 en Rust.

Sobre su comparación entre los lenguajes Rust y C menciona que:

«No hay absolutamente ninguna posibilidad de que no tenga que lidiar con la administración de acceso concurrente, intentos de acceder a áreas de memoria posteriores al lanzamiento y todo tipo de otros problemas si tuviera escrito esto en C. ¡Todos los problemas de concurrencia desaparecen con Rust! ¡La memoria se libera cuando es necesario! Una vez que aprenda cómo hacer que Rust funcione con usted, creo que lo guiará para escribir un código decente, incluso más allá de las promesas de seguridad del lenguaje. ¡Es realmente mágico! »

«Hay mucho debate sobre si Rust es útil o no en el núcleo… en mi experiencia, ¡es mucho más útil de lo que jamás imaginé!» «, ella agrega.

Sus comentarios son una especie de repetición de una compilación de razones técnicas que probablemente justifiquen desechar el lenguaje C en favor de Rust. De hecho, el 15,9% de las 2288 vulnerabilidades que han afectado al kernel de Linux en 20 años (cifras del diccionario Common Vulnerabilities and Exposure (CVE)) están vinculadas a fallas en el lenguaje C, problemas relacionados con la gestión de la memoria: desbordamientos de búfer, asignaciones no liberada, acceso a áreas de memoria no válidas o liberadas, etc.

Además, los principales mantenedores del kernel de Linux están familiarizados con el lenguaje C, cuya edad ya se considera que entra dentro de la 3ra edad. Una nueva generación de mantenedores cuyo grupo de edad está en la treintena está ascendiendo y, por lo tanto, es probable que aumente la dificultad de encontrar mantenedores para el kernel de Linux si su desarrollo continúa en el lenguaje C. Razones por las que Linus Torvalds abrió la puerta al kernel desarrollo en Rust.

Sobre la cuestión de la posibilidad de descartar el lenguaje C, el creador del lenguaje C enumera una serie de razones por las que es probable que fracasen las iniciativas que van en esta dirección:

La cadena de herramientas del lenguaje VS

El lenguaje C no es solo el lenguaje en sí, sino también todas las herramientas de desarrollo desarrolladas para este lenguaje.

¿Quieres hacer un análisis estático de tu código fuente? – Hay mucha gente trabajando en esto para C. ¿Herramientas para detectar pérdidas de memoria, carreras de datos y otros errores? Hay muchos, incluso si su idioma está mejor equipado.

Si se desea apuntar a una plataforma poco conocida, es probable que esté utilizando C. El estado de C como la lingua franca de la computación hoy en día hace que valga la pena escribir herramientas para ella, y se escriben muchas herramientas.

Si alguien tiene una cadena de herramientas de trabajo:

¿por qué arriesgarse a cambiar el idioma? Una «mejor C» debería generar mucha productividad adicional para motivar el tiempo dedicado a configurar una nueva cadena de herramientas. Queda por ver si esto es posible.

Las incertidumbres de un nuevo idioma

Antes de que un idioma alcance la madurez, es probable que tenga errores y se modifique significativamente para abordar los problemas semánticos del idioma. ¿Y el lenguaje es incluso consistente con el anuncio? Puede ofrecer algo como «tiempos de compilación excepcionales» o «más rápido que C», pero estos objetivos resultan difíciles de lograr cuando el lenguaje agrega la

¿Y los mantenedores? Claro, se puede bifurcar un lenguaje de código abierto, pero dudo que muchas empresas estén interesadas en usar un lenguaje que podrían verse obligados a mantener más adelante. Apostar por un nuevo idioma es un gran riesgo.

El hecho de que el idioma podría no ser lo suficientemente bueno

¿El lenguaje aborda los puntos débiles reales de C?

Resulta que la gente no siempre está de acuerdo en cuáles son los puntos débiles de C. La asignación de memoria, el manejo de matrices y cadenas a menudo son complicados, pero con las bibliotecas adecuadas y una buena estrategia de memoria, se pueden minimizar.

¿Acaso el lenguaje no aborda problemas que a los usuarios avanzados realmente no les importan? Si es así, su valor real podría ser mucho menor de lo esperado.

Y lo que es peor, ¿qué pasa si el lenguaje omite características cruciales que están presentes en C? ¿Características en las que confían los programadores avanzados de C? Este riesgo se incrementa si el diseñador del lenguaje no ha usado mucho C, pero viene de C++, Java, etc.

Falta de desarrolladores experimentados para un nuevo idioma

Un nuevo idioma naturalmente tendrá un grupo mucho más pequeño de desarrolladores experimentados. Para cualquier empresa mediana o grande, este es un gran problema. Cuantos más desarrolladores estén disponibles para una empresa, mejor estará.

Además, si la empresa tiene la experiencia de reclutar desarrolladores de C, no sabe cómo reclutar para este nuevo lenguaje.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.