Linux 0.11 reescrito en Rust idiomático, arranca en QEMU
Un kernel temprano de Linux 0.11 ha sido reescrito en Rust idiomático y logrado arrancar en QEMU, lo que ha provocado debate sobre el tamaño del código, la legibilidad y si la seguridad y las abstracciones de Rust justifican la complejidad añadida. Muchos sospechan que gran parte fue generada por IA, lo que plantea dudas sobre el valor educativo, la autenticidad y la mantenibilidad a largo plazo de estas reescrituras. En un sentido más amplio, los comentaristas discuten la creciente tendencia a “Rustificar” bases de código existentes en C y Zig con ayuda de LLM, sopesando la seguridad de memoria y la modernización frente al hype, la dependencia de herramientas y el cansancio cultural.
Alcance de la reescritura y recuento de líneas
- Los comentaristas señalan que el repositorio en Rust tiene muchas más líneas que las fuentes originales en C (inicialmente ~50k frente a ~8–12k SLOC).
- Otros señalan que:
- Un desglose muestra ~15k líneas para el kernel; el resto son herramientas, utilidades y programas de userland.
- Los comentarios, las pruebas y las abstracciones adicionales en Rust contribuyen al tamaño.
- Se debate la diferencia de verbosidad: algunos ven Rust como más explícito/verboso, otros dicen que puede ser tan conciso o más corto que C para funcionalidades equivalentes.
Participación de IA y preocupaciones sobre “slopware”
- Varios comentaristas sospechan que grandes partes fueron generadas por un LLM (basándose en el estilo del README, los emojis y el lenguaje de “abstracciones idiomáticas”).
- Algunos consideran esto aceptable o incluso ideal para un proyecto de juguete / prueba de concepto que nadie ejecutará en producción.
- Otros se muestran frustrados por los “proyectos de tokens” generados por IA, viéndolos como autopromoción de bajo esfuerzo y menos impresionantes que las reescrituras hechas por humanos.
- Hay preocupación de que las reescrituras con IA a menudo solo trasladen patrones inseguros a “unsafe Rust” sin beneficios reales de seguridad.
Idiomaticidad, legibilidad y seguridad de Rust
- A algunos comentaristas les parece que la implementación del fork de Rust es similar o incluso más corta que C para syscalls concretas (p. ej.,
fork). - Otros critican la versión en Rust por ser “onerosa”:
- Muchas líneas sirven para abstracciones, manejo de errores o restricciones del lenguaje más que para la lógica central.
- El uso intensivo de cierres anidados y la inferencia de tipos compleja se consideran perjudiciales para la legibilidad y requieren herramientas sólidas.
- Los partidarios argumentan que los enums explícitos de Rust, los tipos y el borrow checking reducen clases de errores y pueden justificar reescrituras.
Propósito y valor del proyecto
- Se reconoce ampliamente como un esfuerzo de juguete / educativo / prueba de concepto (Linux 0.11 no es prácticamente útil hoy).
- Algunos ven valor en:
- Demostrar que un kernel puede ser “Rustificado”.
- Explorar reescrituras de gran escala asistidas por IA y flujos de trabajo.
- Otros argumentan que el valor educativo se pierde si un LLM hizo la mayor parte del código.
Reacción más amplia contra Rust y los LLM
- Varias टिप्पणarios expresan cansancio con:
- Los anuncios constantes de “X reescrito en Rust”.
- La combinación de evangelización de Rust y reescrituras generadas por IA.
- Los contrapuntos enfatizan:
- El papel creciente de Rust reemplazando C inseguro, incluso en userland y kernels.
- Que la experimentación y los proyectos secundarios “divertidos” aún deberían fomentarse.