加载失败
这条讨论源于一篇题为“Memory Safety for Skeptics”的文章，作者试图回应对语言层面内存安全的怀疑与冷感。评论引用了多位业界与研究者的观点：Herb Sutter（C++ 社区的重要声音）建议把目标设为“可实现的95%”，Michael Hicks（编程语言研究者）提出能力型指针以形式化内存访问，Burak Emir 的博客把未定义行为作为衡量内存安全的核心。讨论同时涉及具体语言与生态的比较——Rust（系统编程语言）、Ada（面向实时/嵌入式的强类型语言）、Zig（新兴系统语言）与 C++ 的实现细节——并把企业漏洞统计与政府级的 memory-safe roadmaps 作为实证与政策讨论的依据。
评论指出反对内存安全的人并非只是文章里的稻草人：不少 C++ 开发者相信靠手工实践就能避免问题，甚至把最坏后果简单等同于 SEGFAULT，这体现了对内存安全本质的误解。业界权威的观点也不一致，Herb Sutter 主张将目标设为“可实现的95%安全”，而极端怀疑者如 Dan O'Dowd 认为只要程序员“get gud”就足够。大型厂商的漏洞统计以及 Zig 的受欢迎程度被用来说明内存安全并非已被普遍视作默认基线。总体而言，评论认为仍需大量外展与教育才能改变态度与实践。
讨论集中在如何精确定义“内存安全”。有人引用 Michael Hicks 的能力型指针模型以及 Burak Emir 将内存安全等同于避免未捕获错误（untrapped errors / 未定义行为）的论点，认为定义应当是形式化的而不是列举错误清单。批评指出原文暗示静态检查为优选，但 Java 等通过大量动态检查（空指针与边界检查）也能实现内存安全，而 Rust 虽强调静态借用检查，在边界上仍有运行时保护。另有评论认为从实践出发把“禁止内存破坏漏洞”作为定义（如政府级别的 memory-safe roadmaps）是可行的，但争议仍在于范围与可检验性。
评论里争论用内存安全语言替代 C/C++ 是否必然牺牲性能。有人提到 Ada（一个面向实时/嵌入式的强类型语言）长期追求内存安全，另一派援引 Russinovich 的观察称许多 Rust 移植性能更好，部分原因是标准库实现（例如 Rust 的哈希表常优于 C++ 的 unordered_map）。也有观点认为实际基准多半势均力敌：熟练程序员与正确的数据结构选择往往比语言本身更决定性能，错误的库或实现才会放大差异。还有补充指出 Ada 需要 SPARK 才能满足当代定义下的“内存安全”，表明历史语言与现代安全目标并不完全等价。
许多评论提醒不要把内存安全视为万能解；生产环境的安全事故常来自逻辑缺陷、配置错误或社会工程，这些问题并非语言内存模型能解决。有人抱怨在所谓“安全”语言中仍需大量修补漏洞，但也有人解释逻辑错误常比低层内存问题更易被利用，而低层问题虽严重却可能更难检测和复现。测试被比作保险：应买到足够覆盖而非穷尽每一条路径；类型安全、内存安全和线程安全应根据业务重要性与成本进行权衡。评论里还有人直接询问哪些问题是在“安全”语言中特有，以提醒讨论聚焦具体威胁场景。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
评论对文章或引用统计的可追溯性提出质疑，尤其是类似“约70%”这类数字是否能在参考资料中找到。有人直接指出在给出的引用中找不到该具体表述，另有评论援引 Google、Microsoft 等公司的报告来支持内存安全与漏洞占比的关联。整体看法是，理论争论之外需要透明、上下文明确且可重复的度量来支撑迁移决策或政策建议，而非笼统引用模糊百分比作为证据。
未定义行为 (undefined behavior): 指语言规范未定义的执行结果（例如越界访问或使用已释放指针），这类错误不会被可靠捕获，可能导致不可预测的内存破坏与安全漏洞。
静态检查 / 动态检查 (static checking / dynamic checking): 静态检查在编译期通过类型系统或分析工具排除错误；动态检查在运行时进行边界或空指针验证。两者都是实现内存安全的手段，Java 倾向动态检查，Rust 以静态借用检查为主但在某些操作仍依赖运行时检查。
边界检查 (bounds checking): 对数组或指针访问进行上下界验证以防止越界读写，是常见的运行时内存安全防护手段，许多内存安全语言在索引操作上默认执行边界检查。