基于 GCC 的 Rust 编译器取得进展
一个计划中的 GCC Rust 前端正在重新点燃争论：Rust 语言究竟应当拥有多个独立编译器，还是继续依赖规范性的 `rustc` 实现。支持者认为，基于 GCC 的 Rust（gccrs）能够带来 GCC 的分析插件、更广泛的 CPU 和嵌入式支持、GPL 许可的工具链，以及对未来 Rust 语言规范的有价值交叉验证，而安全关键行业正越来越需要这些。批评者则反驳说，重复实现前端会浪费本就稀缺的人力，带来类似 C++ 的碎片化和不兼容“风味”的 Rust，而且现有方案——例如带 GCC 后端的 `rustc` 以及 Ferrocene 认证工具链——已经在不创建平行编译器生态的情况下解决了大多数实际需求。
gccrs 相较于替代方案的动机
- 既定目标：利用 GCC 现有的安全/分析插件，在 GNU-only 工具链环境中为 Linux 支持 Rust，提供一个 GPL 许可、独立于 LLVM 的 Rust 编译器。
- 支持者强调它能更好覆盖仅有 GCC 支持的架构（例如 Dreamcast/SH‑4、旧款 CPU、某些 RISC‑V 配置、mips64），并且在 GCC 已经根深蒂固的地方更易使用。
- 批评者认为，rustc_codegen_gcc（由 rustc 前端驱动、GCC 后端）以更少的工作量就能带来大部分收益，而且已经在编译 Linux 内核。
多个前端与碎片化
- 支持多个实现者认为：这有助于“审计”语言、暴露未充分定义的行为、降低单一实现风险，并在遇到编译器 bug 时给用户更多选择。
- 反对前端分裂者指出：C/C++ 就是警示案例——不同厂商、不同标志、不同 bug 和功能缺口会让可移植代码更难写。许多 Rust 用户重视如今“一个编译器，到处可用”的特性，并担心出现“GNU Rust”或厂商分支。
- 有人认为多个前端主要是在重复劳动，并会给库维护者带来微妙的不兼容问题。
语言规范与标准化
- 许多人认为 Rust 需要正式的规范/标准；据称某些行业和监管机构出于安全关键用途的要求，必须有这一点。
- 也有人说 Rust 已经有 RFC、Reference，以及一个活跃的规范项目；他们认为 C++ 式的 ISO 流程太慢且不必要。
- 讨论中区分了对当前行为的描述性规范与规定行为的 ISO 标准；有些人只想要前者，而不想要后者。
安全关键 Rust 与 Ferrocene
- Ferrocene（一个经过认证的 Rust 工具链）被拿来作为证据，说明 Rust 可以在没有正式语言标准的情况下，通过某个特定编译器版本的详细规范，满足 ISO 26262/IEC 61508 等标准。
- 反方观点：缺少官方语言标准，仍会使 Rust 在某些领域失去资格，而且在某些组织眼里，这会被视为“不够严肃”。
工具链、架构与自举
- 对于那些希望在 GCC 支持但 LLVM 不支持或被忽视的 CPU 上使用 Rust，以及偏好“纯 GNU”或 GPL 工具链的人来说，gccrs 很受欢迎。
- 另一些人指出，GCC 本身就有复杂的自举流程，而二进制工具链和交叉编译已经解决了大多数实际的自举问题。
治理、垄断与演进速度
- 有些人不信任单一实现的“垄断”，希望看到竞争；另一些人则认为，一个开放、由社区运行的标准编译器与企业垄断并不相同，也能避免类似浏览器那样的碎片化。
- Rust 一方面被批评推进新特性太快（导致复杂度上升），另一方面又被批评某些长期呼声很高的特性推进太慢；在一些人看来，多个前端和正式标准会进一步拖慢进展，而在另一些人看来，它们是必要的成熟过程。