…我职业生涯中花费了相当大的一部分时间去寻找并修复内存损坏问题、竞态条件和其他未定义行为在非常大的代码库中。是的，我们在 Clang+LLVM 工具链方面取得了巨大的进步，但编写有错误的 C/C++ 代码仍然非常容易（这一点我在论文中没有看到）。从维护、配置和计算的角度来看，充分利用验证工具的成本很高，而且它们的正确性评估不如高级类型系统。通过高级类型系统来防止这类错误似乎是一种更好的方法来降低总体拥有成本，因为：1. 一些（修复成本高昂）的错误通过将系统行为编码到类型系统中被消除了。2. 需要各种 CI 运行（如 Address Sanitizer、Thread Sanitizer、Undefined Behavior sanitizer 等）以及它们相关的覆盖率测试用例的需求大大减少，因为这些问题是通过语言定义而被消除的。…
源讨论高级类型系统的可用性：以 Rust 为例原帖 162 条评论 · 导入时统计把你的经验，加入这段讨论。
我认为这源于人们试图用 Rust 来替代快速垃圾回收语言（例如 C#/Java）。与编写正确的 C/C++ 相比，Rust 的认知负担要小得多，但比编写内存会自动处理的代码要困难得多。
完整原文因为对于大多数软件来说，'足够好'是最好的结果。 用户并不关心你是否用 Rust 编写的（除非目标受众是开发者）。他们只关心它是否解决了他们实际的问题：一个现实世界中的、令人头疼的问题。 如果你用 Rust 编写它需要多花 20% 的时间，这是短期成本，但会带来长期收益，但用户不会这么想。从用户、销售、市场、产品甚至工程部门的人都希望产品尽快发布，所以总是有压力。 用户并不关心你是否需要更少 30% 的 CI 服务器。CEO 也不关心是否需要一个额外的开发人员花时间确保 ASAN、UBSAN 等正常运行。这些成本已经被计入定价中。覆盖率指标被用作质量的代理指标。 同时，开发人员则在处理软件本身的复杂性，这需要精神资源。任何额外的复杂性都会增加负担。…
完整原文因为该语言的资源分配方式不是像'跨领域问题'那样，而是贯穿于该语言编写的每一个非平凡程序中。很长一段时间里，我们有四种风格：静态分配、纯手动管理动态资源、垃圾回收（通常伴随手动管理某些资源），以及'别担心'，用于真正高级的声明式语言。RAII 在此之上增加了一些内容，但 C++ 并没有放弃 new 和 delete（或 malloc 和 free... 或任何东西），所以它并不是一个全新的范式。然而，Rust 为大多数程序员带来了一种真正的新东西，并且需要重新思考思维方式，因此值得考虑是否值得。
完整原文在大多数情况下，与确定要构建什么、建立用户基础以及避免因初期迭代速度慢而失败相比，TCO（总拥有成本）并不那么重要。如果项目成功，软件带来的价值往往超过成本，因此在生命周期的后半段，发现更多需要构建的东西比优化软件费用更为重要。 当然也有例外情况，有时候软件带来的潜在收益较小且有限，需求在前期就已确定，实现路径也已经很明确……
完整原文我仍然对能在 Rust 中编写整个模拟器而没有遇到堆损坏、使用后释放或主机代码中的段错误（与客体代码，即被模拟的代码相反）感到惊叹。这是一门真正了不起的语言。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。