我认为与 Rust 相比，C++ 仍然是一个更理想的编程平台
C++ 和 Rust 的支持者们就“在新的系统编程中，C++ 是否仍然是更优选择”展开讨论，在 C++ 的成熟度、性能、生态和更大的人才池，与 Rust 更强的安全保证和更统一的工具链之间权衡。许多人认为，虽然纪律严明的 C/C++ 团队可以避免大多数内存 bug，但这会付出很高的生产力成本，而且仍然会留下微妙漏洞的空间；相比之下，Rust 的借用检查器、enum/模式匹配、错误处理以及基于 Cargo 的工作流能在构建阶段就捕获整类问题。也有人指出 Rust 的一些差距和权衡——例如嵌入式与共享库场景、二进制体积、生态质量以及 async 的复杂性——并得出结论：Rust 正在稳步侵蚀 C++ 的领域，但尚未完全取代它。
语言采纳与使用场景
- 许多有长期 C++ 背景的评论者，如今在新的绿地项目和个人爱好项目中默认选择 Rust，理由是生产力和安全性；但在受限于遗留代码、现有库或公司政策时，他们仍会使用 C++。
- 也有人坚定地坚持使用 C 或 C++（包括“现代 C++”），认为只要足够自律、工具到位并做好测试，内存 bug 已经少到可以接受，Rust 的优势对他们并不具有吸引力。
- 大家普遍认同，由于其庞大的存量基础、现有工具链以及在嵌入式/设备领域的覆盖，C++“不会消失”。
工具、构建系统与生态
- Rust 的 Cargo 加 crates.io 被广泛称赞为一大优势：一个统一的构建系统、简单的依赖管理、直接的交叉编译。
- 另一些人批评 crates.io 有“npm 式”问题：大量 0.x 的爱好者 crate、冗长的依赖链、同一二进制中出现多个版本、缺乏命名空间和审核机制；一些大型组织会将依赖内置并自行管理。
- C++ 的构建工具碎片化（CMake、Bazel、自定义系统）被视为一大痛点，不过也有人认为，成熟的 C++ 构建系统在某些企业工作流中可能优于 Cargo。
安全性 vs “自律”
- 一派观点认为，纪律严明的 C/C++ 团队配合 sanitizers、fuzzing 和严格实践，基本可以避免内存崩溃；他们认为 Rust 的安全性被过度抬高。
- 另一派反驳说，即使是顶级 C/C++ 项目（内核、浏览器、数据库）仍然会带着内存漏洞发布，而静默的内存损坏远比偶发的段错误更糟。
- 安全性被表述为“保持不变量”，Rust 的类型系统和借用检查通过设计本身减少了整类 bug。
性能与优化
- 有人认为，Rust 的明确溢出行为和边界检查会带来不可忽视的开销，因此 C++ 的未定义行为为最大化优化自由提供了正当性。
- 另一些人回应称：
- Rust 提供了 checked/wrapping/saturating 等算术原语，可用于显式控制。
- 编译器通常可以消除边界检查。
- 与 UB 和内存 bug 的工程成本相比，通常的开销很小。
- Unsafe Rust 被强调为一个有针对性的“逃生口”，而不是放弃安全性。
语言特性与易用性
- Rust 受到称赞的地方包括：表达力强的 enum/ADT 和模式匹配、基于 Result/Option 的错误处理、基于 Send/Sync 的并发、更清晰的编译器错误、内建的 lint 和格式化，以及一致的工具链。
- C++ 则被认为拥有更丰富的 constexpr/const-generics、placement new、分配器控制、SIMD，以及更深厚、实战检验更充分的库生态。
- 一些人认为，试图定义“安全的现代 C++ 子集”本质上是受限的，而且不如 Rust 明确定义的安全子集实用。
二进制体积、链接与嵌入式
- Rust 默认静态链接其标准库，生成的二进制往往会明显大于使用共享库的 C++，这在存储受限的嵌入式或设备类系统中很重要。
- LTO、以体积优化为目标的配置文件，以及
no_std可以缩小 Rust 二进制，但有人仍认为，在多二进制系统中，共享的 C/C++ 库在空间效率上更高。