这是一种响应于GCC-RS（SHNATSEL）的更简单替代品编写的意见片，解释了为什么我支持GCC-RS项目，以及rustC_Codegen_GCC不是替代它。虽然RustC_Codegen_GCC，确实提供了GCC-RS的一些好处，但它不提供所有的所有优势。特别是具有独特的前端有益，即将在这篇文章中地址的后端。这是从LCCC作者的角度来看，其中包括生锈语言的不同替代实施，但它进一步完成然后GCC-RS。
一般来说，多次实现是一个好主意。虽然可以表明，至少首先，C和C ++有问题，它是我的经验，这通常不再是这种情况。因为我对我提供了选择，我可以根据可用的功能和符合标准选择我想要支持的编译器。我最近介绍了Microsoft Visual C ++的非合规性错误，可防止C ++代码编译。我选择不支持MSVC，直到该错误是固定的，而且由于GCC和Clang等替代方案，就可以这样做。使用RustC，如果我有合法问题，我不能选择使用不同的编译器，我可以选择重新设计代码或完全放弃生锈。事实上，这是LCCC的一个问题，该问题将用Rust编写，但缺乏任何稳定的ABI在比C更高的水平。
在铁锈前端的空间中竞争将使编译器作者修复错误并以其他方式改进的原因，并为用户提供当这些错误存在时，超越“完全解决”或“完全删除语言”。
然而，这一点没有“然而”。如果它介绍了生锈语言的建立的“特征”并制造了有限，或者不努力，因此完全有可能导致生态系统造成勃起，如果引入了建立的“功能”，或者没有努力解决它们。但是，部分解决方案将是某种的适当规范，我稍后会解决。当然，另一方面将通过拒绝支持违反规范的实施来持有对修复非符合性错误的实现。但是，这将自然需要一个适当的规范，因为缺少一个，用户可以将其代码保持为原因，因为所有实现都需要完全模仿任何其他实现，包括它是错误和未指定的行为。
关于引导，具有从任何任意点引导编译器的能力可能很有用，而不是仅仅将编译器引入该平台。它可用于软件的安全性和安全验证，以便能够从一些已知的好软件（如C编译器）开始，并在没有进入不受信任的域的情况下从那里积聚。
此外，虽然MRESTC可以用来缩短自举链，但它不会缩短到合理的限制，因为它只能在我检查的最后一次建立RUSTC 1.39（这是在发布本文之前几周的几周）。 RUSTC 1.N能够建立锈的1.N + 1，电流稳定的锈蚀器是1.52（1.54夜晚）。因此，要从MRESTC到达目前的稳定锈，因此必须至少构建13个不同的rustc版本，至少。虽然这肯定比52个版本更好，但它仍然需要完全不合理的时间。相比之下，在从C编译器开始的C ++ 98（写入GCC-RS的版本的版本中，使用Rust编译器，序列很简单：
在GCC-RS案例中，有2个引导步骤。在MRESTC-RUSTC案例中，有15个引导步骤。在C ++ 11,14,17或20中编写的编译器将有3个步骤（GCC 4，GCC 10，目标），并以RUST编写的编译器，目标MRESTC将具有4（GCC 4，GCC 10，MRESTC，TARGED ）。所有这些都明显小于15，但是15的潜在未绑定的链条改善，至少有53步。此外，作为RustC，GCC昂贵昂贵，构建时昂贵。在我的系统上，Rustc大约需要6个半小时来构建2个阶段。具有 - 启用-obotstrap（对于GCC是可选的，并且可以在执行手动引导时忽略），此时间仅为2¼小时（与禁用 - bootstrap有40分钟）。 GCC 4的构建也明显较小，更便宜，只需40分钟 - Enable-Bootstrap（在使用GCC 10时修补现代Linux之后）。
此外，MRESTC仅能够靶向X86。因此，在RISCV或AARCH64上执行此减少，并且用于对这些平台进行启动，必须建立每个版本的RUSTC。
此外，即使在不需要安全/安全验证时，交叉编译也可以引入不必要的RUSTC（可能需要几分钟，到几个小时）。例如，在从头开始的Linux类似指令后构建Linux环境时，交叉编译RustC将涉及在每个阶段（工具，工具和Chroot）构建它。具有易于引导的编译器将允许某人构建这样的系统，尽可能迟到构建生锈编译器，而不是交叉编译会允许。在为IGLUNIX构建RustC时，此问题出现了，这是一个不包含任何GNU组件的自托管Linux发行版。
具有多种实现的一个原因是帮助提示语言的规范。有人认为，Miri已经这样做了，但是，这是为了这个目的而不是足够的，因为这三个主要原因是：
Miri只执行程序的动态分析。它只能检查评估的代码路径（而不是所有可能的代码路径和所有可能的情况）。通过扩展，您只能检查有条件编译的代码，您能够为其构建和运行。您无法在没有Windows计算机（或虚拟机）的情况下检查在Windows上启用的代码。
此外，Miri并没有真正有助于指定它，因为它遵循的规则是争用，并且具有有限的例外，例如堆叠的借助别名模型和原子内存模型（由于生锈代表到C ++而导致的原子内存模型）语言），不能在理论上考虑，如书面散文规范。
MIRI也无法检查使用内联组件或FFI调用的代码，这可能是在使特定代码中有定义（或未确定）行为的情况。因此，Miri无法确认所有生锈代码是否具有定义行为，即使所有规则都牢固定义。
Ferrocene项目也有助于指定语言，但我认为拥有多种实施者的经验，在设计该规范中的设计将是进一步的有利的，而不是那些在RustC前端和该项目的设计方面的那些。
虽然RustC_CodeGEN_GCC确实解决了RUCTRY GCC-RS Propports来解决的许多问题，但它并没有提供后者可能导致的所有好处。此外，MRESTC的存在勉强减轻了自动启动问题，以及MIRI 在推理完全是关于给定的生锈代码的行为的推理是没有用的，正确规格的方式是。 由于这些原因，其中包括一个无情，我支持gcc-rs，我希望我能够确信你也支持它。