Progreso hacia un compilador Rust basado en GCC

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

Un frontend de Rust planeado para GCC está reavivando el debate sobre si el lenguaje debería tener múltiples compiladores independientes o seguir dependiendo de la implementación canónica `rustc`. Sus defensores argumentan que un Rust basado en GCC (gccrs) aportaría acceso a los complementos de análisis de GCC, un soporte más amplio para CPU y sistemas embebidos, herramientas con licencia GPL y una comprobación cruzada valiosa para una futura especificación del lenguaje Rust, que las industrias críticas para la seguridad exigen cada vez más. Los críticos responden que duplicar el frontend desperdicia esfuerzo escaso, arriesga una fragmentación y “sabores” incompatibles de Rust al estilo C++, y que los esfuerzos existentes —como `rustc` con un backend de GCC y la toolchain cualificada Ferrocene— ya cubren la mayoría de las necesidades prácticas sin crear un ecosistema paralelo de compiladores.

Motivación para gccrs frente a alternativas

  • Objetivos declarados: usar los complementos existentes de seguridad/análisis de GCC, dar soporte a Rust para Linux en entornos de toolchain solo GNU, ofrecer un compilador Rust con licencia GPL e independiente de LLVM.
  • Quienes lo apoyan destacan una mejor cobertura de arquitecturas solo soportadas por GCC (por ejemplo, Dreamcast/SH‑4, CPUs heredadas, algunas configuraciones RISC‑V, mips64) y un uso más sencillo donde GCC está fuertemente arraigado.
  • Los críticos argumentan que rustc_codegen_gcc (backend de GCC impulsado por el frontend de rustc) ofrece la mayoría de los beneficios con mucho menos esfuerzo y ya está compilando el kernel de Linux.

Múltiples frontends y fragmentación

  • A favor de múltiples implementaciones: ayuda a “auditar” el lenguaje, expone comportamientos poco especificados, reduce el riesgo de depender de una sola implementación y da opciones a los usuarios cuando encuentran errores del compilador.
  • En contra de los frontends múltiples: se citan C/C++ como advertencias: distintos proveedores, flags, errores y lagunas de funcionalidades hacen más difícil el código portable. Muchos usuarios de Rust valoran hoy la propiedad de “un compilador, funciona en todas partes” y temen un “GNU Rust” o bifurcaciones de proveedores.
  • Algunos sugieren que múltiples frontends duplican en gran medida el esfuerzo y crean incompatibilidades sutiles para los mantenedores de bibliotecas.

Especificación del lenguaje y estandarización

  • Muchos sostienen que Rust necesita una especificación/estándar formal; según informes, algunas industrias y reguladores lo exigen para usos críticos de seguridad.
  • Otros dicen que Rust ya tiene RFC, una Reference y un proyecto de especificación activo; ven un proceso ISO al estilo C++ como lento e innecesario.
  • Se distingue entre una especificación descriptiva del comportamiento actual y un estándar ISO prescriptivo; algunos quieren lo primero sin lo segundo.

Rust para seguridad crítica y Ferrocene

  • Ferrocene (una toolchain Rust cualificada) se cita como prueba de que Rust puede cumplir estándares como ISO 26262/IEC 61508 sin un estándar formal del lenguaje, mediante una especificación detallada de una versión concreta del compilador.
  • Contrapunto: la ausencia de un estándar oficial del lenguaje sigue descalificando a Rust para algunos dominios y es percibida como “no seria” por ciertas organizaciones.

Toolchains, arquitecturas y bootstrap

  • gccrs es bien recibido por quienes quieren Rust en CPUs soportadas por GCC pero no por LLVM o desatendidas, y por quienes prefieren una toolchain “puramente GNU” o GPL.
  • Otros señalan que el propio GCC tiene un bootstrap complejo y que las toolchains binarias y la compilación cruzada ya resuelven la mayoría de los problemas prácticos de bootstrap.

Gobernanza, monopolios y velocidad de evolución

  • Algunos desconfían de un “monopolio” de una sola implementación y quieren competencia; otros argumentan que un compilador canónico abierto y gestionado por la comunidad no es comparable a un monopolio corporativo y evita la fragmentación al estilo de los navegadores.
  • A Rust se le critica tanto por avanzar demasiado rápido en algunas funciones (complejidad) como por ir demasiado lento en otras largamente solicitadas; algunos ven los frontends múltiples y un estándar formal como más carga, y otros como una maduración necesaria.