文章探讨了内存安全领域的绝对主义倾向，指出虽然Rust开发者常被关联，但作者并非针对他们。文章对比了Rust通过编译时检查强制内存安全与其他系统语言（如C、C++、Zig）依赖程序员自行确保安全的差异。

文章主旨重述

本文探讨了内存安全领域的绝对主义倾向，批评了部分开发者对Rust语言的不公正指责，并呼吁以务实态度看待不同技术方案。

核心内容

1. 背景与争议
   传统上，C/C++/Zig等语言依赖程序员手动保障内存安全，而Rust通过编译时检查（辅以unsafe）减少漏洞。近期，Fil-C项目（及Zig的“fil”编译模式）提出通过垃圾回收和指针追踪技术，使C/C++代码在内存访问错误时崩溃而非产生漏洞。这引发了争议：部分人（包括Fil-C作者）声称Rust因存在unsafe而“不安全”，并认为推广Fil-C才是真正关心内存安全。

2. 对绝对主义观点的反驳

   • 技术权衡：Fil-C虽能消除内存漏洞，但存在ABI不兼容、性能下降（可能慢数倍）、引入垃圾回收等代价。许多大型项目（如系统软件）无法接受这些限制，而Rust恰好适合此类场景。
   • 实践数据：以Android平台为例，500万行Rust代码仅发现1个内存安全漏洞（密度0.2/百万行），而C/C++的漏洞密度约为1000/百万行。Rust在实践中已显著降低风险。
   • 非黑即白的谬误：绝对主义者要求“100%安全”，但现实中需权衡。例如，Fil-C将漏洞转为崩溃，虽优于安全漏洞，但大量崩溃仍需修复。此外，攻击者可能利用崩溃触发其他安全问题。

3. 结论
   作者主张务实态度：不同项目应选择适配的技术（如Fil-C适用于可接受其代价的C/C++项目，Rust适用于需高性能或低层控制的场景）。若绝对主义者真正关心安全，应同等批评使用C/C++/Zig（非Fil模式）的开发者，而非仅针对Rust。

根据评论内容，总结主要观点如下：

1. 内存安全的重要性与争议焦点 - 支持Rust的编译时安全：多数评论认为Rust的编译时检查优于运行时检查，能提前发现逻辑错误（评论4、26）。关键引用："A memory issue is a logic bug. Fil-C simply moves that from undefined behavior/security issue/incorrectness to a crash."（评论4）；"Compile-time checks mean I basically never spend time debugging runtime crashes"（评论26）。 - Fil-C的运行时安全方案：部分评论认可Fil-C通过运行时检查（如fat pointers）提升C语言安全性，但指出其性能代价（评论18、29）。关键引用："Fil-C is basically an alternate ABI and libc runtime"（评论2）；"The problem is that they provide an excuse to keep using terrible programming languages like C and C++"（评论25）。

2. 语言选择的政治化与情绪化 - Rust vs Fil-C/Zig的争论：多位评论者指出这场争论已演变为“宗教战争”，语言创造者刻意煽动对立（评论3、7）。关键引用："Pizlo is not a memory safety absolutist. His rhetoric towards rust is a tactic specifically designed to draw more attention"（评论3）；"It's annoying how many comment sections online are now just Rust vs Fil-C/Zig flamewars"（评论7）。 - “反觉醒”标签：有评论认为Rust被贴上“觉醒”标签，而C/Zig/Odin成为“反觉醒”语言（评论7）。关键引用："Rust is the 'woke' language and C/Zig/Odin are now the 'anti-woke' languages"（评论7）。

3. 对Rust的批评与反思 - Rust的局限性：部分评论指出Rust并非完美，如无法表达自引用借用、Drop实现受限等（评论6）。关键引用："Rust's type systems cannot express self-referential borrows"（评论6）；"Rust deliberately chooses to have an unsafe subset"（评论19）。 - Rust的“安全绝对主义”矛盾：有评论质疑Rust支持者一方面强调内存安全，另一方面又接受unsafe子集（评论13）。关键引用："Why is the place Rust stops now suddenly good enough?"（评论13）。

4. 对C/C++的批判 - C/C++的长期不作为：多位评论者批评C/C++标准委员会长期忽视边界检查等基础安全特性（评论29）。关键引用："Missing bounds checks are by far the biggest source of vulnerabilities and they're a problem in exactly 2 languages"（评论29）；"C++ only now in C++26 is finally adding bounds checks"（评论29）。

5. 其他观点 - 内存安全的定义争议：有评论指出“内存安全”是术语，Java/Python等GC语言同样安全，争论“最安全”语言是范畴错误（评论21）。关键引用："Almost every Java, Python, Ruby, Javascript, and Go program is memory safe"（评论21）。 - 工具链与模型检查：部分评论认为应关注模型检查等工具，而非语言之争（评论16）。关键引用："Tooling does what these languages can't do. I have had great success model checking C with CBMC"（评论16）。 - 个人自由与安全权衡：少数评论从哲学角度反对“安全绝对主义”，认为应保留犯错自由（评论24）。关键引用："Freedom is not worth having if it does not include the freedom to make mistakes"（评论24）。

总结：评论呈现明显对立——Rust支持者强调编译时安全与可靠性，Fil-C支持者主张运行时检查的实用性，而多数评论者认为语言之争已偏离技术本质，演变为情绪化对立。核心分歧在于：内存安全应通过编译时（Rust）还是运行时（Fil-C）实现，以及是否应接受性能代价。