El caso a favor de Rust en el sistema base

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

Desarrolladores y usuarios de FreeBSD están valorando si adoptar Rust en el “sistema base” del sistema operativo — el kernel central, libc y las utilidades estándar que se incluyen en cada instalación. Quienes lo apoyan destacan la seguridad de memoria de Rust, su sistema de tipos más fuerte y sus herramientas modernas como una forma de reducir vulnerabilidades y permitir componentes de sistema más robustos, mientras que los críticos advierten sobre una mayor complejidad de compilación, un soporte débil para algunas arquitecturas y el riesgo de fracturar un proyecto tradicionalmente conservador y centrado en C. Muchas voces sugieren un uso gradual y selectivo de Rust y una coordinación más estrecha con las herramientas Rust upstream en lugar de un cambio total.

Alcance: qué significa “sistema base” en FreeBSD

  • Incluye el kernel, libc (estrechamente vinculada al kernel), utilidades básicas, dtrace y los compiladores necesarios para construir la base.
  • Se entrega y actualiza como una unidad cohesiva única (parches binarios), distinta de los “ports” y los paquetes de terceros.
  • La cultura del proyecto tiende hacia una base reducida; lenguajes como Perl fueron eliminados; la cadena de herramientas de LLVM es ahora el principal “bloat”.

Motivaciones para Rust en el sistema base

  • Deseo de un objetivo Rust estable en FreeBSD y una mejor integración para herramientas del sistema (por ejemplo, jails, administración de ZFS).
  • Se considera valioso que los desarrolladores principales tengan acceso a código Rust específico de FreeBSD como orientación.
  • Creación más sencilla de ISOs personalizadas que incluyan utilidades de administración basadas en Rust.
  • Algunos quieren que Rust reemplace a C++ en la base y sacar OpenSSL a ports, usando bibliotecas TLS de Rust para herramientas como fetch.

Rust frente a C/C++: seguridad y características del lenguaje

  • Garantías estáticas más fuertes sobre seguridad de memoria y carreras de datos mediante ownership/borrowing y el borrow checker.
  • Los movimientos destructivos y el manejo claro de objetos “prestados” frente a “propietarios” previenen muchos errores de use-after-free e invalidación de iteradores que en C/C++ quedan para el tiempo de ejecución o el comportamiento indefinido.
  • Se elogian las herramientas modernas (Cargo), conceptos más ricos de biblioteca estándar y patrones avanzados de tipos/iteradores/monádicos; se reconoce una curva de aprendizaje pronunciada.
  • Debate sobre cuán diferente es realmente esto de RAII en C++, pero hay consenso en que Rust hace mucho más difíciles los errores de lifetime y concurrencia.

Preocupaciones de plataforma y cadena de herramientas

  • El soporte tier‑1 de Rust es limitado; FreeBSD soporta más arquitecturas, aunque esa lista se está reduciendo.
  • Hay dudas de que FreeBSD tenga recursos o interés para llevar los targets de FreeBSD a Rust tier‑1.
  • Sugerencias: usar el frontend GCC Rust o compiladores que generen C (por ejemplo, mrustc) para plataformas de largo plazo, aunque se cuestiona su practicidad.
  • Algunos sostienen que las arquitecturas heredadas que no pueden seguir el ritmo de las cadenas de herramientas modernas ya están en “tiempo prestado”; otros ven a los BSD como el último bastión para ese hardware.

Problemas de compilación, tamaño e integración

  • Preocupación por duplicar los tiempos de compilación ya pesados, centrados en LLVM, si Rust entra en la base.
  • Discusión sobre añadir una etapa extra de compilación para componentes dependientes de Rust después de buildworld, y/o desacoplar las toolchains de world.
  • Tensión entre mantener la base mínima e integrar Rust profundamente.

Seguridad, fiabilidad y pruebas

  • Varios comentarios vinculan el 60–70% de las vulnerabilidades graves con la inseguridad de memoria y ven Rust como un remedio parcial.
  • Otros subrayan que la mayoría de los ataques a gran escala siguen siendo problemas “básicos” y que Rust no resuelve todos los problemas de seguridad.
  • Debate sobre si importa más la elección del lenguaje o la disciplina de pruebas/QA; varios sostienen que las garantías del lenguaje reducen directamente la carga de pruebas y ciertas clases de errores.
  • A algunos les preocupa que Rust en kernel/nivel bajo siga estando lleno de unsafe y añada complejidad, socavando la simplicidad que se valora en núcleos de sistemas operativos seguros.

Mocking, estrategia de pruebas y experiencia de desarrollo

  • Ejemplo: un conjunto de pruebas para un sistema de archivos FUSE con mocking intensivo se argumenta que sería prácticamente inviable en C, pero manejable en C++/Rust.
  • Contraargumento: el mocking en sí mismo suele ser una mala estrategia de pruebas, independientemente del lenguaje.
  • Elogio general de las herramientas y la infraestructura de pruebas de Rust, aunque el mocking en Rust no gusta universalmente.

Ecosistema, filosofía e impacto en la comunidad

  • Comparaciones: FreeBSD/Go se ven como conservadores y estables; Linux/Rust como rápidos de evolución y flexibles.
  • Algunos temen que Rust en la base pueda ser divisivo y desestabilizador, comparándolo con una escisión al estilo “emacs vs vi”.
  • Otros ven una introducción selectiva (componentes no del kernel, nuevos daemons) como una vía razonable que no reemplazará de inmediato a C, sino que ampliará las opciones.