21CTO导读：似乎现在一些C++项目做着做着，就想转到Rust，那么它们全都适合转换吗？

Rust 的内存安全机制正在推动许多团队重新评估 C++，尤其是在系统服务、网络组件、解析器和新建基础设施中。

但是可以确定的是，“Rust 会完全取代 C++”并不符合工程现实。

在极低延迟交易、GPU 与 AI 计算、成熟游戏引擎生态，以及需要精确掌控内存布局的并发系统中，C++ 仍然拥有难以快速替代的技术积累。关键是不在于哪门语言绝对更好，而在于项目对延迟、内存控制、工具链、生态和安全的具体要求。

核心/关键要点

• C++ 在微秒级尾延迟、定制内存布局和复杂无锁设计中仍具显著优势。
• Rust 能实现高性能底层功能，但复杂共享内存设计常需要受控的 unsafe 代码。
• CUDA、Unreal Engine 和成熟中间件使 C++ 在 AI 与游戏领域难以快速替代。
• 对多数团队，按模块混合使用 Rust 与 C++ 比全面重写更现实。

先说结论：Rust 与 C++ 是按场景分工，而不是简单胜负

Rust 和 C++ 都可用于高性能、底层和资源敏感的软件。两者在合适的实现方式下，性能可以非常接近。Rust、Clang 等现代工具链都能利用 LLVM 等成熟的优化基础设施，因此“C++ 编译出的二进制必然更快”并不是可靠结论。

真正拉开差距的往往是以下因素：

• 能否表达特定的底层设计，例如无锁共享结构、侵入式容器和自定义内存回收。
• 延迟是否必须严格可预测，而不是只追求平均吞吐量。
• 生产工具链是否已经成熟，包括编译器、分析器、调试器、SDK 和优化库。
• 团队是否依赖既有生态，例如游戏引擎、插件、中间件和人才供给。
• 内存安全风险是否高于极限控制需求。

Rust 的价值在于默认降低大量内存错误风险。C++ 的价值则在于提供极深的硬件控制能力，并拥有数十年形成的行业工具链。现实中的最佳选择通常是混合策略，而不是一次性全盘迁移。

为什么超低延迟交易仍偏向 C++

高频交易是 C++ 最具代表性的应用之一。这类系统面对的不是“程序运行得快不快”，而是每次请求都必须在极短时间内完成决策、风险检查、订单发送和网络传输。

以一个约 30 微秒的交易时间预算为例，系统可能只有几微秒用于判断和风控，剩余时间还要留给网络传输。哪怕额外增加十几微秒，也可能失去成交机会。为缩短物理传输距离，行业甚至会将基础设施部署在距离交易所匹配引擎极近的位置，并投入建设低延迟网络。

垃圾回收暂停会破坏延迟预算

在延迟极其严格的热路径中，程序不能出现不可预测的暂停。带垃圾回收的语言可能具备很高吞吐量，但一次毫秒级垃圾回收暂停，相比几十微秒的预算会大出几个数量级。

这并不代表 Java、Go 或其他托管语言不能用于金融系统。它们可以承担数据处理、服务层、分析或特定架构中的任务。只是对于必须持续响应的核心热路径，运行时暂停会成为必须规避的风险。

无锁并发与复杂内存关系是核心挑战

低延迟系统常见的设计包括：

• 用原子操作协调线程，而不是依赖互斥锁。
• 用无锁环形缓冲区在网络线程与交易逻辑之间传递市场数据。
• 使用侵入式数据结构，让同一个对象同时属于多个链表或队列。
• 采用专用的内存回收和对象池，避免热路径上的常规分配。

锁意味着等待，而等待会造成不可预测的尾延迟。C++ 允许开发者直接选择内存地址、控制对象构造、缓存行对齐和内存池布局。例如 placement new 可在指定位置构造对象，适合 arena 分配器与预分配对象池。

Rust 也能实现原子操作和无锁环形缓冲区，标准库提供了原子类型支持。但当设计涉及复杂指针关系、共享可变状态和内存回收时，编译器未必能静态证明全部操作安全。

此时通常需要使用原始指针和unsafe。

这并不意味着 Rust 失去意义。成熟的 Rust 做法是将小范围的危险实现封装进经过严格审计的安全抽象中，让大多数业务代码仍保有安全保证。但如果最关键的热路径本身大量依赖原始指针、原子操作与手工回收，C++ 往往能以更直接的方式表达该设计。

C++ 为什么常常胜过 C

当项目已经需要手动控制内存和并发时，C 与 C++ 都是候选项。C++ 的优势是：既能保留接近 C 的控制能力，也能使用泛型、类型系统和可在编译期消除成本的抽象。

这意味着团队不必反复手写通用容器、类型分派和基础设施。对性能敏感的代码而言，抽象若能在编译期展开，就不必带来额外运行时成本。

C++ 标准也持续吸收低延迟领域长期使用的技术。C++26 相关提案涉及hazard pointers与RCU等并发内存回收工具，这些能力此前常由高性能团队自行实现。

AI 与 GPU 编程：C++ 的优势主要来自 CUDA 生态

在 AI 基础设施中，C++ 的竞争力不只来自语言本身，更来自 NVIDIA CUDA 及其周边的完整生产环境。CUDA 是建立在 C++ 扩展之上的 GPU 编程平台，训练和推理栈中的大量核心能力围绕它发展。

典型组成包括：

• CUDA，用于编写和编译 GPU 加速程序。
• cuBLAS，提供高性能线性代数和矩阵运算。
• cuDNN，提供神经网络常用算子。
• TensorRT，用于优化推理部署。
• PyTorch ATen，其核心实现与 C++ 深度绑定。

Rust 进入 GPU 领域并非没有进展。Rust-CUDA、rust-gpu 等项目正扩展 Rust 的 GPU 编程能力，研究成果也表明 Rust 可以达到很高的 GPU 性能水平。例如一项 NVIDIA Research 工作报告称，其 Rust 矩阵乘法实现曾达到 cuBLAS 在 B200 上约 96% 的性能。

但研究原型、高性能内核实验与大规模生产栈不是一回事。现阶段，CUDA 的编译器、性能分析器、调试器、海量调优内核和企业部署经验仍集中在 C++ 生态中。因此，对需要直接深入 NVIDIA GPU 栈的团队，C++ 往往是风险更低的选择。

游戏开发为什么仍是 C++ 的主场

游戏行业的语言选择尤其受生态影响。一个大型游戏并不只是某个团队拥有的一份代码，它还连接着引擎、插件、物理系统、音频、渲染、中间件、平台 SDK、构建工具和外包协作流程。

Unity 可使用 C# 编写脚本，但引擎底层包含 C++。Unreal Engine 则从核心到扩展都深度支持 C++，其官方 C++ 编程文档体现了这种工作流。

Embark Studios 是一个很好的例子。

该团队广泛采用 Rust，并推动过 rust-gpu 等项目，但《ARC Raiders》仍基于 Unreal Engine 5 构建，C++ 是核心技术栈的一部分。这说明 Rust 与 C++ 并不必然互斥：

• Rust 可以适合工具、服务、构建系统和游戏外部基础设施。
• C++ 可以继续承担引擎集成、性能关键模块和既有 SDK 对接。
• 新项目可以逐步增加 Rust，而不必重写整个引擎生态。

游戏开发还高度依赖快速试验。玩法代码常会在短周期内被写出、测试并废弃。若团队已深度熟悉 C++ 和 Unreal 的调试及迭代流程，转换语言不仅是语法学习问题，还会影响原型速度、资产管线和插件兼容性。

Rust 的借用检查器并非缺点，但会改变设计边界

Rust 的借用检查器通过所有权和借用规则，阻止许多悬垂指针、数据竞争和重复释放问题。对于长期维护的大型系统，这类默认保障非常重要，也是 Rust 获得采用的主要原因。

不过，借用检查器的目标正是限制未经明确协调的共享可变内存。某些传统 C++ 低延迟设计把多层指针关系、侵入式容器和自定义生命周期管理放在一起，这会与 Rust 的安全模型产生摩擦。

应避免两种误解：

• 误解一：Rust 无法完成复杂底层任务。
   Rust 可以通过原子操作、unsafe 和封装完成这些工作。
• 误解二：只要用了 unsafe，Rust 就毫无价值。
   将少量高风险代码隔离并审计，仍比让风险扩散至整个代码库更容易管理。

更合理的问题是：复杂的底层部分在整个系统中占多大比例？如果只有少量模块需要危险操作，Rust 的封装模式可能非常有价值。如果最核心、最大比例的路径都依赖这种操作，C++ 的表达方式可能更自然。

内存安全压力下，C++ 正在如何回应

内存安全已成为软件供应链和产品安全的重要议题。CISA 将部分内存不安全实践列为产品安全风险，Google 也在其安全设计与内存安全观点中强调了这一问题。对于新建、网络暴露且安全敏感的组件，Rust 因而具备明显吸引力。

C++ 社区并未忽视这个挑战。目前讨论中出现了两条主要路线：

Safe C++：引入更强的静态安全模型

Safe C++ 提案试图将类似借用检查的能力带入 C++，以更严格的方式防止部分内存安全问题。其吸引力在于把安全能力提升到语言模型层面。

难点是兼容性。全球已有规模巨大的 C++ 存量代码。若新安全模型要求大量迁移，团队在承担迁移成本时，也会自然评估是否应直接采用 Rust 或其他替代方案。

Profiles：以配置和规则约束既有 C++

另一条路线是安全 profiles，即通过编译器诊断、编码约束与特定配置，逐步减少不安全用法，而不要求立刻改写所有遗留代码。其优势是更贴近存量代码治理，适合渐进式改造。

根据相关委员会进展，profiles 曾以 C++26 为目标，但未能及时纳入，后续工作指向 C++29。无论最终标准化路径如何，C++ 的安全改进都需要时间，而组织当前做出的技术决策不能只等待未来标准。

选择 Rust 还是 C++：一个实用决策框架

选择语言前，先把“性能”拆成可衡量的需求。以下清单能帮助团队避免被流行叙事左右。

更适合优先评估 Rust 的情况

• 项目是新建的网络服务、系统组件或命令行工具。
• 内存安全缺陷可能造成较高的安全、稳定性或合规风险。
• 大部分代码不需要复杂的共享可变图结构。
• 团队希望在默认情况下防止数据竞争和生命周期错误。
• 关键依赖库和部署环境已经支持 Rust。

更适合继续使用 C++ 的情况

• 热路径对微秒级尾延迟、固定内存位置和缓存布局有严格要求。
• 系统依赖无锁结构、侵入式容器、定制回收或高比例的底层指针操作。
• 项目紧密依赖 CUDA、成熟 C++ SDK 或专有硬件工具链。
• 产品构建在 Unreal Engine 或庞大的 C++ 游戏中间件生态之上。
• 团队已有成熟 C++ 人才、测试体系、性能分析流程和长期维护经验。

最常见也最务实的方案：混合使用

不必将语言选择理解为全有或全无。可以让 C++ 保留在引擎、GPU 内核、极端低延迟模块或已有 ABI 边界内，同时让 Rust 承担新服务、工具、协议解析、控制面或安全敏感组件。

这种方式的前提是边界清晰：定义稳定的接口，明确跨语言对象所有权，限制 FFI 层的复杂度，并为每个边界建立测试与性能基线。混合架构不是免费午餐，但通常比全量重写更能控制迁移风险。

避免这 5 个 Rust 与 C++ 选型误区：

1. 把平均基准测试当作全部性能。
    对交易、实时系统和交互引擎，最坏延迟和抖动可能更重要。
2. 认为 LLVM 相同就代表工程成本相同。
    编译结果相近，不代表内存模型、生态和调试体验相同。
3. 把 unsafe 当作 Rust 失败。
    小而受控的 unsafe 核心可以是合理的架构边界。
4. 把旧代码一律视为不可迁移。
    存量代码可迁移，但应按安全风险、维护成本和接口价值排序。
5. 忽略工具链和人才。
    语言只是系统的一部分，生产环境中的 SDK、分析工具、插件和团队技能同样决定成败。

最终判断：Rust 不会消灭 C++，但会改变 C++ 的使用边界

Rust 正在成为需要内存安全的新系统项目的重要选项，并会持续进入过去由 C++ 主导的领域。但 C++ 在极端低延迟、精密内存控制、CUDA 计算和游戏引擎生态中的优势，仍然地位稳固。

因此，最好的问题不是“Rust 会不会取代 C++”，而是：在这个模块中，哪种语言能以可接受的风险，满足性能、可靠性和交付速度要求？

作者：场长

来源：

https://www.youtube.com/watch?v=QNPwKMOQIKM