Rust：“快速行动并打破事物”是道义上的当务之急

Rust破坏了很多东西，而且方式难以修复。这可能会对用户，特别是那些使用较旧或较慢硬件的用户产生寒蝉效应。 Rust只有一个实现，支持的平台范围非常狭窄，几千万行C ++代码，并且没有规范。 Rust表面上支持几十个目标，但是可以合理地预期只有第1层平台可以工作。作为试图在第二层平台上引导Rust（并失败）的人，我可以向您保证，这是一场噩梦。将其引入一个全新的目标将是一种地狱般的体验。让任何与Rust一起工作的发行包装商分享他们的恐怖故事-他们有很多。

Rust货物开始停顿并重新评估。切换到Rust会让那些在x86_64 oraarch64上甚至超出Linux / macOS / Windows规范的人都无法使用。即使在受支持的平台上，它也对构建要求构成了沉重负担，要求10x到100x或更多的RAM，CPU时间和功耗。不管它有什么好处，选择Rust最终都会选择将一大批人拒之门外，并注定要遭受更多的挣扎和挫折。这些是您需要认真考虑的实际取舍。

精打细算已成为道德上的当务之急。好吧，这是一个道德上的争论：每两年扔掉可维修的计算机进行升级是一种特权，并非您的所有用户都拥有，它有助于气候变化并填埋。就安全性而言，有些事情需要规范：旧硬件是唯一可以避免专有固件斑点，Intel ME或AMD PSP和UEFI的类型。在Rust的主流或破产制度下，解决诸如微代码之类的新硬件和诸如POWER9和RISC-V之类的开放式硬件也受到了困扰。任何被遗弃的人都被迫使用您遗弃的旧C代码库，这对它们的安全性要比您试图从中拯救它们的假设错误要差得多。

C不是内存安全的。它遭受不确定的行为。这些是有效的投诉。但是，C代码是安全的！只需看一下seL4，在Iguarantee中，您发现的bug比RedoxOS少。还有大量未经正式验证的C程序也可以正常工作。重写您的代码Rust总是会引入新的bug，包括安全性bug，如果您仅维护C代码就不会出现。也许在您的C代码库中潜伏着未被发现的错误，但是随着您的代码库在持续维护下的老化，这个数字只会减少。

可以用成千上万的代码行编写有效的C工具链（例如cproc和qbe）。唯一有效的Rust工具链是数以千万计的C ++和Rust代码行。比较时，您认为这两个工具链有多少个未发现的错误？其中有多少个安全问题？调试它们或将其移植到新的或旧的平台将需要多少相关工作？这些各自的代码库多久流失一次，造成更大的维护负担并引入新的错误/漏洞？我可以在大约10分钟内引导可用的C工具链。我花了一个星期试图为Rust做那件事，但失败了。那很重要。

铁锈有点酷，但不是万能药。出于正当理由，无论是从技术上还是从道德上来说，都首选toprefer C，Rust在为稳定性，可靠性，简单性和可访问性优先的系统中的黄金时间准备工作之前仍需要进行大量工作。我们中使用这种系统的人，感觉像Rust社区已经将自己的拇指放在自己的集体耳朵上，唱出“ la la la”来解决我们的问题，然后像踩着乐高玩具的孩子玩“ Godzilla”一样，脚整个软件生态系统。 ，却一直因为我们老又老气而大喊大叫。

对Rust团队：是时候冷静下来了。放慢语言速度，编写规范，专注于改善第2层和第3层目标，扩展到更多平台，并致力于性能，稳定性和可访问性。投资更多的第三方实现，例如rust-gcc。我花了将近一个星期的时间，全职试图为Rustcv64-musl制作Rust。引导过程绝对是错误的。您的生态系统存在影响真实人的实际问题。现在该停止忽略它们了。