Comprometerse con Rust para código del kernel

Artículo original ↗ Discusión en Hacker News ↗

El paso de Linux a permitir Rust en el desarrollo del kernel está provocando debate sobre si puede reemplazar de forma segura y eficiente parte del código C de larga data, especialmente en drivers donde los errores de seguridad de memoria son comunes. Los partidarios destacan el modelo de propiedad de Rust, sus sólidas comprobaciones estáticas y las capacidades de `no_std` como herramientas potentes para una programación de sistemas más segura sin sacrificar rendimiento, mientras que los críticos señalan tiempos de compilación más lentos, la complejidad del código `unsafe` y las preocupaciones sobre dependencias de la cadena de herramientas en LLVM y C++. Se mencionan alternativas como Zig por estar filosóficamente más cerca de la “cultura C”, pero la relativa madurez de Rust y su uso ya existente en sistemas de bajo nivel lo convierten en el principal candidato para una adopción incremental en el kernel.

Experiencias de migración de C→Rust

  • Los equipos que migran informan que Rust obliga a pensar más a fondo sobre la propiedad de los datos, los tiempos de vida y los patrones de “múltiples lectores, un escritor”.
  • Este cambio mejora el diseño incluso cuando luego se escribe en C.
  • El manejo de errores mediante Result/Option y match, las pruebas en línea y las herramientas de documentación se consideran grandes mejoras de productividad.
  • Varios afirman que las bases de código en Rust son significativamente más concisas y se sienten menos frágiles que sus equivalentes en C.

Datos dinámicos y manejo de JSON

  • Algunos dicen que Rust hace que las tareas muy dinámicas (p. ej., esquemas JSON en tiempo de ejecución, tablas de BD desconocidas) sean “un poco más कठिन” que en lenguajes dinámicos.
  • Otros argumentan que sobre todo es más verbosidad, no una limitación real, y señalan crates existentes que hacen validación de esquemas JSON en tiempo de ejecución.

Rendimiento en tiempo de compilación

  • Quejas: los tiempos de compilación de Rust son “horribles” frente a C y pueden desanimar su uso.
  • Contraargumentos:
    • Para proyectos moderados, las compilaciones limpias terminan en un par de minutos en portátiles típicos.
    • En comparación con C++, Rust suele compilar tan rápido o más rápido una vez que las características son comparables.
    • Los árboles de dependencias pesados y los traits/macros perjudican más los tiempos de compilación; Rust del kernel (no_std, pocas dependencias) debería ir mejor.
  • Los benchmarks que comparan Rust y coreutils en C muestran tiempos de compilación dentro de un factor aproximado de 2×, según qué trabajo de preparación se cuente.
  • Se sostiene que la monomorfización por sí sola no es el principal culpable; haría falta un diseño de lenguaje fundamentalmente distinto para lograr mejoras drásticas.

Rust en el kernel y la programación de sistemas

  • Gran entusiasmo: la seguridad de memoria de Rust se considera crítica para los drivers, donde los errores de concurrencia y los patrones inseguros están muy extendidos.
  • Se cita evidencia de que los errores de seguridad de memoria en el kernel se introducen más rápido de lo que se corrigen; Rust se propone como una mitigación estructural.
  • Escépticos:
    • Cuestionan la idoneidad de Rust para bare metal y sistemas de latencia ultrabaja, y no les gusta la dependencia de LLVM, basado en C++.
    • Algunos prefieren Zig por estar culturalmente más cerca de C y ser más hostil a grandes dependencias de la cadena de herramientas, pero reconocen que Zig aún no es lo bastante estable.
    • Un intento en trading de baja latencia con Rust informa que el último 20% crítico para el rendimiento fue extremadamente difícil en Rust seguro; unsafe se sentía más peligroso que C.
  • Los partidarios responden que:
    • La mayor parte del trabajo de bajo nivel puede aislarse en pequeñas secciones unsafe, beneficiándose el resto de la seguridad.
    • Rust puede operar a niveles de abstracción parecidos a C (especialmente con no_std), al tiempo que permite abstracciones de alto nivel y coste cero cuando es apropiado.

Cadenas de herramientas y LLVM/GCC

  • El kernel se compila cada vez más con Clang; siguen existiendo fallos, pero la competencia en herramientas se considera beneficiosa.
  • Algunos se quejan de que LLVM es difícil de construir sin GCC/binutils/glibc; otros sostienen que esto es una preocupación de nicho y señalan que GCC también depende de C++.