Originally posted by evasb
View Post
The big issue with the "new frontend" approach is that it's a complex, never-ending project. It'll forever be playing catch-up with rustc in terms of features. It'll have a different set of bugs than rustc. It'll have a slower release cadence. It'll be an added burden for crate authors who are asked to support it. Not of these issues come up with the "new backend" approach : it's a simpler project, that can get feature-complete and enter maintenance mode. It provides the exact same portability benefits and doesn't risk splitting the ecosystem.
IMHO the reasons for gccrs are more political/emotional than technical/pragmatic. For example a preference for GPL over MIT. Or the dogma that having multiple frontends will always be good for the language (it was true in the pre-FOSS pre-Github world of C/C++/Javascript, but it's unlikely nowadays). Or the sectarian "LLVM is bad" reactions (forgetting that rustc isn't tied to LLVM). Or the fact that it's more fun and ego-boosting to write a new frontend than connect an existing frontend to an existing backend.
Comment