I have asked this question before, but why write an entirely new frontend, which is an enormous task if you want to reach a similar quality to rustc? rustc_codegen_gcc¹ adds gcc as a backend to rustc alongside llvm, miri and (wip) cranelift. As a result, it always works with the newest version of rust and is already nearly complete after less work.

¹https://github.com/rust-lang/rust/tree/master/compiler/rustc...

FSF wants to support Rust as a first-class language in GCC, which means their own implementation and ability to bootstrap without dependence on other projects.

Having two independent implementations is good for finding code depending on compiler bugs. The development will also highlight where the Rust language is not documented/specified enough yet.

The GCC implementation may end up with a different design, and perhaps faster compile times, or at least we'll know whether Rust is inherently slow to compile, or is that just rustc. Rustc supporting multiple back-ends can't have as close integration with GCC's back-end as GCC's own front-end.

> Having two independent implementations is good for finding code depending on compiler bugs.

I'd go as far as to claim that having multiple independent implementations is a basic requirement for any programming language which has any aspirations of being production-ready.

Thats just silly, there are a lot of production ready languages that only have one full implementation such as Typescript, Elixir etc

> (...) such as Typescript

It seems you're oblivious to the fact that projects such as swc[1] exist, and have been adopted by projects such as deno.

[1] https://swc.rs/

> Elixir etc

I'm not familiar with Elixir nor am I in a googling mood. Nevertheless that was an awfully short list. Why is that?

swc only does transpilation, it does not support TypeScript's type-checking which is its main feature.

Here is an interview with them: https://www.totaltypescript.com/rewriting-typescript-in-rust