Progresso rumo a um compilador Rust baseado em GCC

Artigo original ↗ Discussão no Hacker News ↗

Um frontend planejado de Rust para o GCC está reacendendo o debate sobre se a linguagem deve ter múltiplos compiladores independentes ou continuar a depender da implementação canônica `rustc`. Defensores argumentam que um Rust baseado em GCC (gccrs) traria acesso aos plugins de análise do GCC, suporte mais amplo a CPUs e embarcados, ferramentas com licença GPL e uma valiosa verificação cruzada para uma futura especificação da linguagem Rust, que indústrias críticas de segurança exigem cada vez mais. Críticos respondem que duplicar o frontend desperdiça esforço escasso, arrisca fragmentação no estilo do C++ e versões incompatíveis de “Rust”, e que esforços existentes — como o `rustc` com backend do GCC e a toolchain qualificada Ferrocene — já atendem à maioria das necessidades práticas sem criar um ecossistema paralelo de compiladores.

Motivação para o gccrs vs. alternativas

  • Objetivos declarados: usar os plugins de segurança/análise já existentes do GCC, oferecer suporte a Rust para Linux em ambientes de toolchain apenas GNU, e fornecer um compilador Rust com licença GPL e independente do LLVM.
  • Defensores destacam melhor cobertura de arquiteturas suportadas apenas pelo GCC (por exemplo, Dreamcast/SH‑4, CPUs legadas, algumas configurações de RISC‑V, mips64) e uso mais fácil onde o GCC já está consolidado.
  • Críticos argumentam que o rustc_codegen_gcc (backend do GCC conduzido pelo frontend do rustc) entrega a maior parte dos benefícios com muito menos esforço e já está compilando o kernel Linux.

Múltiplos frontends e fragmentação

  • Pró-múltiplas implementações: ajuda a “auditar” a linguagem, expor comportamento subespecificado, reduzir o risco de uma única implementação e oferecer opções aos usuários quando encontram bugs no compilador.
  • Contra frontends múltiplos: C/C++ são citados como alertas — diferentes fornecedores, flags, bugs e lacunas de recursos tornam código portátil mais difícil. Muitos usuários de Rust valorizam hoje a propriedade de “um compilador, funciona em todo lugar” e temem “GNU Rust” ou forks de fornecedores.
  • Alguns sugerem que múltiplos frontends apenas duplicam esforço e criam incompatibilidades sutis para mantenedores de bibliotecas.

Especificação da linguagem e padronização

  • Muitos argumentam que Rust precisa de uma especificação/standard formal; alguns setores e reguladores supostamente exigem isso para uso em sistemas críticos de segurança.
  • Outros dizem que Rust já tem RFCs, uma Reference e um projeto de spec ativo; um processo ISO no estilo C++ é visto como lento e desnecessário.
  • Faz-se uma distinção entre uma spec descritiva do comportamento atual e um padrão ISO prescritivo; alguns querem a primeira sem a segunda.

Rust para sistemas críticos de segurança e Ferrocene

  • Ferrocene (uma toolchain Rust qualificada) é citado como prova de que Rust pode atender a padrões como ISO 26262/IEC 61508 sem uma especificação formal da linguagem, por meio de uma spec detalhada de uma versão específica do compilador.
  • Contra-argumento: a ausência de um padrão oficial da linguagem ainda desqualifica Rust para alguns domínios e é percebida como “não séria” por certas organizações.

Toolchains, arquiteturas e bootstrapping

  • O gccrs é bem recebido por quem quer Rust em CPUs suportadas pelo GCC, mas não pelo LLVM ou negligenciadas, e por pessoas que preferem uma toolchain “puramente GNU” ou GPL.
  • Outros observam que o próprio GCC tem bootstrapping complexo e que toolchains binárias e cross-compilation já resolvem a maior parte dos problemas práticos de bootstrapping.

Governança, monopólios e velocidade de evolução

  • Alguns desconfiam de um “monopólio” de implementação única e querem competição; outros argumentam que um compilador canônico aberto e gerido pela comunidade não é como um monopólio corporativo e evita fragmentação ao estilo dos navegadores.
  • Rust é criticado tanto por avançar rápido demais em features (complexidade) quanto por ser lento demais em algumas há muito pedidas; múltiplos frontends e um padrão formal são vistos por alguns como ainda mais atraso, e por outros como maturação necessária.