Why I support GCC-rs.
This is an opinion piece written in response to The Simpler Alternative to GCC-rs (Shnatsel), explaining why I support the GCC-rs project, and why rustc_codegen_gcc is not a substitute for it. While rustc_codegen_gcc, does provide some of the benefits of the gcc-rs, it does not provide all of them. There are benefits specifically to having a distinct frontend, over just the backend, which I will address in this article. This is from the perspective of an author of lccc, which includes a different alternative implementation of the rust language, though it is further from completion then gcc-rs.
Havi ng multiple implementations, in general, is a good idea. While it can be shown that, at least to begin with, C and C++ had issues with it, it is in my experience this is generally no longer the case. Because I have options available to me, I can choose the compilers I want to support based on the available features and compliance with the standard. I recently raised a Non-compliance bug with Microsoft Visual C++ that prevents my C++ code from compiling. I’ve chosen not to support MSVC until that bug is fixed, and am able to do that because of alternatives like gcc and clang. With rustc, if I have a legitimate issue, I cannot choose to use a different compiler, I can either choose to redesign the code or abandon rust entirely. In fact, this was an issue with lccc, which would have been written in rust but for the lack of any stable ABI at a higher level than C.
Having competition in the space of rust front ends would give reasons for the compiler authors to fix bugs and otherwise improve, and give users options for when those bugs are present, beyond just “work around it” or “drop the language entirely”.
