内存安全绝对主义者
系统编程中的内存安全是一个激烈争论的焦点：一边是支持 Rust 编译期保证的人，另一边是主张 Fil-C 及类似运行时检查方案、用于遗留 C/C++ 代码的人。评论者权衡更严格的安全模型、性能开销、生态破坏和开发体验，指出 Rust“基本安全”但仍依赖 `unsafe` 和 FFI，而 Fil-C 则可以在牺牲速度的情况下加固现有代码库。许多人认为，语言选择应由实际的安全与可靠性目标来驱动，而不是部落式的“语言战争”；形式化验证和模型检查等工具的重要性，可能与语言本身同样大。
内存安全作为目标及其局限
- 许多人认为，内存安全应当成为默认预期，尤其是对广泛使用的软件以及任何处理不受信任输入的东西（编解码器、TLS、浏览器、操作系统）。
- 其他人指出，现实世界中的事故往往更多由社会工程、供应链攻击、逻辑错误和配置问题引发，而不是内存破坏。
- 若干评论强调：内存安全是必要的，但远远不够；其他类别的错误（例如类似 Log4Shell 的逻辑/设计缺陷）仍然存在。
Rust、Fil-C/Zig、GC 语言
- Rust 因结合了高性能、强类型系统、所有权模型和良好的工具链而受到赞赏；许多人表示，它的价值远不止于“安全版 C++”。
- Fil-C 被视为一种有吸引力的方案，可为现有 C/C++ 叠加安全性，并通过强运行时检查来实现，但代价是性能下降，以及在运行时崩溃而不是编译期拒绝。
- 有人认为 Fil-C 可以严格地更“安全”（没有逃生通道），而 Rust 和 GC 语言有
unsafe/FFI 边界；也有人反驳说，如果 unsafe 很少且被良好隔离，这种区分在理论上才有意义。 - 一些人偏好 Zig 和 C，因为它们提供指针级表达能力和底层控制，尽管也承认其中存在风险。
编译期与运行时安全
- Rust 的编译期保证因可靠性更高、调试更少而受到重视；仅靠运行时方案被视为把未定义行为变成崩溃，这虽更好，但仍然令人痛苦。
- 其他人更看重“在任何地方都能被捕获”而不是“在编译期被捕获”，并接受运行时检查、胖指针或 Fil-C 风格的机制。
遗留的 C/C++ 与替代方案
- 大型遗留生态（内核、工具链、GUI 栈、GPU API）使得“全部重写为 Rust/GC 语言”并不现实，这推动了 Fil-C 和类似方案的出现。
- 一些人遗憾于 C/C++ 历史上拒绝标准化更安全的构造（例如带边界检查的 slices/spans），尽管已有数十年的内存安全语言经验。
安全工具、操作系统/硬件与形式化方法
- 模型检查、静态分析和形式化验证（CBMC、Kani、WUFFS、已验证编译器/操作系统）被视为语言级方案的补充，甚至更优。
- 硬件问题如 rowhammer 和比特翻转（ECC 可缓解但不能消除）表明，“内存安全语言”并不等于“物理上安全的内存”。
语言战争与文化
- 许多人对 Rust 与 Fil-C/Zig 的部落主义和意识形态化叙事（“觉醒 vs 反觉醒”、“居高临下的布道”）感到沮丧。
- 若干人呼吁进行务实、面向具体领域的权衡讨论，而不是绝对主义的“唯一正确语言”立场。