2019 年了，Rust 到底比 C++ 强在哪里？

2019年了，Rust 到底比 C++ 强在哪里？说实话，这个问题就像在问：2019年的智能手机和2019年的诺基亚3310比，谁更强？它们强在不同的维度，解决不同的问题。C++ 依然是那个在性能、系统控制方面无出其右的老将，而 Rust 则像一位新兴的、带着一身“黑科技”的新秀，在安全性、现代性方面展现出惊人的潜力。

如果要深入聊聊 Rust 到底比 C++ 强在哪里，我觉得可以从以下几个核心点来掰扯掰扯：

1. 内存安全，或者说，它把“谁该为这个内存泄漏负责”这个问题，从运行时变成了编译时。

这绝对是 Rust 最最核心的优势，也是它一出生就备受瞩目的原因。C++ 在内存管理上，给了开发者极大的自由，但也正是这份自由，带来了无数的坑：

空指针解引用 (Null Pointer Dereference): C++ 里 `nullptr` 满天飞，一不小心就程序崩溃。Rust 的所有权系统和借用检查器，强制你在访问数据之前，确保它一定存在。这种检查是在编译阶段完成的，编译器会告诉你：“嘿，这里你可能要访问一个不存在的东西，赶紧处理一下！”
悬垂指针 (Dangling Pointers): C++ 中，你可能分配了一块内存，用完之后释放了，但某个地方却还保留着指向这块内存的指针。当你试图通过这个指针访问数据时，就是栽坑。Rust 的借用规则，保证了借用的生命周期不会比被借用的数据长。如果数据被释放了，任何指向它的引用都会自动失效，编译器会告诉你：“这个引用已经过期了，不能用了！”
数据竞争 (Data Races): 在多线程编程中，多个线程同时读写同一块内存，并且至少有一个是写操作，这就会导致数据竞争，结果是不可预测的，简直是噩梦。Rust 的所有权系统在多线程环境下依然有效，它的“Send”和“Sync” trait 机制，强制你在编译时就确保共享数据的安全性。编译器会检查你是否正确地实现了这些 trait，从而阻止数据竞争的发生。

C++ 也有智能指针 (`std::unique_ptr`, `std::shared_ptr`) 来帮助管理内存，但它们本质上还是在运行时进行引用计数或者所有权转移。一旦出现逻辑错误，这些工具也救不了你。Rust 则是通过一套严格的、在编译时就能静态分析的规则，从根本上杜绝了这类问题。你可以想象成，C++ 是让你自己带着炸药包去排雷，而 Rust 是给你一个金属探测器，并且在炸药包周围都贴上了“危险！”的标签。

2. 现代化的语言特性，让写代码这件事没那么“痛苦”。

C++ 发展了这么多年，虽然一直在进步（C++11, C++14, C++17, C++20...），但它仍然保留了很多历史包袱，导致语言本身有些复杂和冗余。Rust 在设计之初就站在巨人的肩膀上，吸取了很多现代语言的优点：

模式匹配 (Pattern Matching): Rust 的 `match` 表达式，比 C++ 的 `switch` 强大得多。它可以解构复杂的数据类型（比如 `enum`、`struct`），并且会检查所有可能的匹配情况，防止漏掉。这在处理错误、状态机等方面非常有用，代码可读性和健壮性都大大提升。
更友好的错误处理 (Result and Option): C++ 传统的错误处理方式是返回错误码或者抛出异常。返回错误码容易被忽略，抛出异常在某些场景下（比如性能敏感的系统编程）可能不合适。Rust 使用 `Result` 和 `Option` 来显式地表示可能成功也可能失败，或者可能存在也可能不存在的值。编译器会强制你处理这些可能的情况，这让错误处理变得更加明确和安全。
零成本抽象 (Zerocost Abstractions): Rust 致力于提供高级的抽象，但又不会因此带来运行时性能的损耗。比如它的 `Iterator` trait，你可以写出非常简洁、富有表达力的迭代代码，但最终编译出来的机器码，和直接用 C++ 循环写出来的性能几乎没有区别。这使得开发者可以享受高级语言的便利，而不用牺牲底层性能。
包管理和构建工具 (Cargo): 想象一下 C++ 项目里，处理第三方库的依赖、编译选项、链接等等，是不是常常让你头疼？Rust 有一个叫做 Cargo 的集成构建系统和包管理器。它就像 Python 的 `pip` 或者 Node.js 的 `npm` 一样，可以帮你轻松地管理项目依赖、编译、测试、发布。这极大地提高了开发效率，尤其是在处理复杂的项目和依赖关系时。

3. 更好的并发模型，让多核时代不再是“诅咒”。

随着多核处理器的普及，并发编程变得越来越重要。C++ 在并发方面提供了 `std::thread`, `std::mutex` 等工具，但管理这些原始的并发原语，稍有不慎就会引入上面提到的数据竞争等问题。

Rust 的所有权和借用检查器，在并发编程中依然发挥着关键作用。它能够静态地检查并阻止数据竞争，这让编写安全的并发代码变得更容易。Rust 的 `async/await` 语法，也提供了更现代、更高效的异步编程模型，可以让你在不阻塞线程的情况下处理大量的 I/O 操作，这在网络服务、高性能计算等领域非常有优势。

4. 现代化的工具链和社区支持。

Rust 的工具链非常完善，包括上面提到的 Cargo，还有 `rustfmt` (代码格式化工具)，`clippy` (代码风格和潜在错误的检查工具) 等等。这些工具的使用体验非常好，能够帮助开发者写出更规范、更健壮的代码。

Rust 的社区也非常活跃和友好，愿意分享知识和帮助新人。虽然 C++ 社区庞大且历史悠久，但 Rust 社区的年轻活力和对现代开发实践的拥抱，也是其快速发展的重要原因。

当然，Rust 也不是万能的。 C++ 在某些方面依然有着无可比拟的优势：

庞大的生态系统和现有代码基础: C++ 已经存在了几十年，有无数的库、框架和遗留代码。在很多领域，特别是已经成熟的行业，替换现有 C++ 代码库的成本可能非常高。
更低的抽象层级和直接的硬件控制: 在某些对硬件控制到极致的应用场景，比如操作系统内核的一部分、嵌入式设备的底层驱动，C++ 提供的直接内存访问和汇编插入能力，可能比 Rust 的抽象更直接。尽管 Rust 在这方面也在不断进步，但 C++ 在这方面依然是“经验丰富者”。
成熟的编译器和工具链: C++ 的编译器（如 GCC, Clang）已经非常成熟，经过了多年的优化和测试，在编译速度和优化能力上往往更胜一筹。Rust 的编译器（rustc）虽然进步神速，但在大型项目上的编译时间有时候会成为一个挑战。

总结一下，2019年的 Rust，它比 C++ 强在哪里？

它强在内存安全，通过一套在编译时就能强制执行的规则，极大地降低了由于内存管理不当而导致的程序崩溃和安全漏洞。
它强在开发者体验，通过现代化的语言特性、强大的工具链和集成化的包管理，让编写代码这件事变得更高效、更愉快。
它强在并发编程，提供了更安全、更易于管理的并发模型。

如果你正在开发需要极高安全性和可靠性的系统，比如操作系统、浏览器引擎、网络服务、嵌入式系统，或者你对写出没有内存安全问题的代码有执念，那么 Rust 绝对是一个值得你投入时间和精力去学习的语言。它提供了 C++ 级别的底层控制和性能，但用一种更安全、更现代的方式来实现。

当然，如果你只是想快速写个脚本、做个简单的 GUI 应用，或者项目已经有大量的 C++ 代码需要维护，那么 C++ 依然是那个稳妥的选择。

这就像是在问，2019年的 iPhone 和 2019年的诺基亚 3310 谁更强？ iPhone 在功能、体验、应用生态上碾压 3310，但 3310 的续航、坚固程度、耐用性，在某些特定场景下依然是无敌的。Rust 和 C++ 的关系，大概就是这样。

网友意见

我并不是很熟悉 Rust, 所以我产生了一些疑问(当然也希望喜欢 Rust 的人能解答我的问题). 因为我比较熟悉的是 C++ 和 Haskell, 所以会下意识的拿它们来比较.

Rust 在很多地方都吸取了教训, 但造出来的东西虽然正确, 细节上却常有疏忽, 反而更难用，这是我很不理解的, 而且 Rust 官方似乎还没有修复它们的意愿, 甚至连饼都没画给我, 所以我对 Rust 仍然是观望态度, 打算再等 2 ~ 3 年.

先说一些特别细节的问题, 这些问题任意拿出来一个都不算什么, 但合在一起却有理由让我退出.

Rust 的宏常常用来做初始化列表, 而在 C++ 中, 初始化列表并不比 Rust 宏复杂, 而且还可以根据返回值推断.

       auto oneToFive() -> std::vector<int32_t> {     return {1, 2, 3, 4, 5}; }

在这个角度来看, 二者区别是不大的, Rust 这么写

       fn oneToFive() -> Vec<i32> {      vec![1, 2, 3, 4, 5]; }

然而 Rust 的宏对类型推断的支持并不是很好, 而且需要复杂的支持, 因此 HashMap, BTreeMap (和衍生出的两个 Set) 是没有字面量的, LinkedList 也没有. hashmap![] 这么长的东西本来就很丑, 而且标准库还没提供, 这就是问题了.

同时也透漏出另一问题, Rust 对 C++ 的很多 “设计缺陷” 做了编译期的保护, 你无法写出所谓的错误的代码, 这也是我们会被编译期教做人的原因. 而实际上是这个限制有点太过了, 如果你限制了三成正确的写法去提高正确性, 那我没什么问题, 但如果你限制九成正确的写法去提高正确性, 那我宁愿你不正确. 在 if while 等表达式的参数可以省略括号时, Rust 是唯一一个强制省略括号的, 诸如 Swift 的其他语言, 均可以补上括号, 类似让人感到束手束脚的细节有很多.

作为初始化列表的宏其实真的用处不大, 因为我们总是可以这么写

       auto some    = Xxxxxx {1, 2, 3, 4, 5}; // C++ let mut some = xxxxxx![1, 2, 3, 4, 5]; // Rust

当然过程宏我不说了, C++ 没有, 需要用一些复杂的手段来处理.

模式匹配实际上也是让我不太理解的一个点, 模式匹配正常都是来处理 ADT 的, 由于 C++ 根本就没有好用的 ADT 所以并不总是会需要用到. Rust 的模式匹配有些让我非常不理解的细节设计, 比如

范围区间

       // 理想中 match x {     ...0 => Equal::LT,     0    => Equal::EQ,     _    => Equal::GT, }  // 实际 match x {     x if x < 0 => Equal::LT,     0          => Equal::EQ,     x if x > 0 => Equal::GT,     _ => /* 然后编译器还总觉得你不完备 */, }

那我干嘛不写 if-else 呢?

再比如 Optional, 很多语言都有, 甚至辣鸡 C++ 标准库里都有这么一个玩意. 但我们把 Kotlin 和 Swift 拽过来, 情况就大不相同的, 在 Rust 里, ? 被用来处理 Result, 而 Maybe 类型就完全没有语法糖.

       let y = x ?? 3 // 默认值 a?.b()?.c()     // 可选链 a!                // 强制解包

生命周期给函数式编程带来的影响其实是相当大的, 我相信每个新人都会花大量时间弄明白 lambda 参数里的 & 和 && 还有 &&& 到底都是啥, 什么时候需要一个, 什么时候需要两个, 同时还会伴随着一些诡异的代码 *x < 0 , x < &0. RAII 确实很重要, 但是牺牲如此之大我觉得不值得, 我随时都会遇到各种类型不匹配的问题, 如果不是编译器友善的提醒我那些东西的类型, 恐怕我还要在上边花费更多时间. 这时候我对类型推断的疑惑就出现了, 当然我不知道 Rust 实现的到底是啥理论, 没见过我也不好说太多. 但是作为一门类型如此复杂的语言, 还坚持用 let 推断, 这就是我不好理解的地方了.

首先, Rust 有很多明显该推= 出来的东西根本推断不出来, 我不知道为什么, 一些东西的类型非常明显, 属于一眼就能看出来的类型, Rust 却看不懂. 当编译器看不懂的时候, C++ 是很方便的. 只要前缀写上就可以, 而

       let x: Vec<i32> = /* ... */

我能说这有点画蛇添足么. 当然很多语言都用后置类型, 但它们的类型非常简单, 比如 Kotlin, Swift, 它们几乎就没有推断不出来的东西. 我在写 Swift 的时候, 从来不会因为某个变量的类型不够明晰而疑惑, 但 Rust 过于复杂, 又采用了一个极其绕的实现, 这就是让我不舒服的地方.

Rust 可以根据上下文推断类型, 展现了高超的编译器技术, 但我宁愿希望它没有. 如果一个类型的推断是从五行开外的得来的, 那我的眼睛就很难 phrase 这段代码, 而且今后删改的时候就更难处理, 因为我删除某个代码, 甚至可能影响五行开外的推断.

王垠就 diss 过 Rust, 也说过这个不够明确的问题, 但王垠完全没有好好用过这门语言, 以至于出现了不少低级错误, 但对这点的分析我倒是很赞成, 如果他多用用, 很快就会发现这东西不仅是不够明确, 而是极其混乱.

Rust 可以通过函数参数的类型来推断其他类型, 这个功能更让我不理解, 当然 Rust 官方可以生成不喜欢重载(你咋不干脆声称你不喜欢 Ad-hoc 呢?), 因为不重载的函数才有助于这种推断. 然后我想请问: 官方在函数非自动柯里化, 对函数式支持不够好的情况下, 为什么仍然拒绝实现可选参数, 命名参数和不定数量参数?

当然, 还有一些我并不太喜欢的东西, 像 "Hello, World!.to_string()...

如果用惯了 C++ 的人, 很可能会把 C++ 当成某种黑魔法, 有可能造成一些副作用, 需要人类主动的去控制. 而人们对 Rust 的期望是, 既能起到黑魔法的效果, 又能规避大部分错误. 于是它们把咒语写的极其复杂晦涩, 说十句都施不出来正确的魔法, 每个咒语都是绕口令.

那你觉得魔法师会用哪个呢?

类似的话题

2019 年了，Rust 到底比 C++ 强在哪里？

2019年了，Rust 到底比 C++ 强在哪里？说实话，这个问题就像在问：2019年的智能手机和2019年的诺基亚3310比，谁更强？它们强在不同的维度，解决不同的问题。C++ 依然是那个在性能、系统控制方面无出其右的老将，而 Rust 则像一位新兴的、带着一身“黑科技”的新秀，在安全性、现代性方.............
2019年了，买房还被社会默认为男性的责任吗？

2019年了，买房这事儿，还真就没能完全摘掉“男性责任”这顶帽子，尽管社会观念在变，但潜移默化的影响依然存在。先来说说为啥大家觉得“买房是男的责任”。这背后其实是咱们传统观念在作祟。过去，社会分工明确，男性在外打拼挣钱，女性在家操持家务，生儿育女。男性的价值更多体现在经济能力和社会地位上，而买房、养.............
2019年了，大众是否对25%偏置碰撞测试做了优化？

2019年了，大众在25%偏置碰撞测试上，可以说是有着持续的优化和投入。要详细讲，我们可以从几个方面来分析：一、大众对安全测试的重视程度——不仅仅是“做足样子”首先要明白一点，像大众这样的国际大车企，安全性能尤其是碰撞测试的表现，是其品牌形象和市场竞争力的重要组成部分。25%偏置碰撞（Offset.............
2019年了，为什么还有人真的相信美国是世界和平的守护者？

好的，我们来聊聊为什么在2019年，仍然有人相信美国是世界和平的守护者，即使在全球范围内，对美国的角色和意图的看法早已复杂化和多元化。要理解这一点，我们需要深入探讨几个层面，包括历史叙事、地缘政治现实、意识形态输出以及特定群体的情感和利益诉求。首先，历史叙事和“美国例外论”的根基。美国确实在两次世界.............
2019 年了，能用 2k 以下的器材推动 AKG k701 吗?

2019年了，想用2K以内的预算“好好”推一把AKG K701？这个问题其实挺接地气的，毕竟K701当年那可是“监听旗舰”一样的存在，但它的驱动门槛也确实是让人头疼。首先，我们得承认，K701这耳机确实比较“吃力不讨好”。它的阻抗是62欧姆，灵敏度嘛，也不算特别低，但关键是它那个“调音风格”，对推力.............
2019年了，日本人还在用一次性木筷子么？

关于日本人是否还在用一次性木筷子这个问题，答案是肯定的，他们确实还在使用，但情况比过去要复杂和微妙一些。用“还在用”来概括可能有些片面，更准确的说法是：一次性木筷子在日本依然存在，但其使用情况正在发生变化，并且受到多方面因素的影响。为了更详细地说明这个问题，我们不妨从几个方面来展开：1. 传统与便.............
2019 年了，中超联赛现在在国际足坛上是什么水平？

2019年的中超联赛，可以说是在国际足坛上处于一个相当“尴尬”但又充满潜力的位置。要说它“什么水平”，得拆开来看，因为它不像欧洲五大联赛那样有一个清晰、统一的定位。从球员水平来看：高水平外援是联赛的“门面”：2019年，中超联赛依旧是靠着那些来自欧洲、南美等地的顶级外援来撑起门面。像佩莱、塔尔.............
2019 年了，C# 发展得怎么样了？

2019 年，C 这门语言的生命力依然旺盛，并且在持续进化中，展现出了扎实的根基和面向未来的决心。微软对 C 的投入从未停歇，一年一度的 .NET 平台更新，也就是 .NET Core 3.0 的发布，为 C 带来了许多令人振奋的新特性和改进。开发者们感受最深切的，莫过于 C 8.0 的到来。这次更.............
2019年了，你遭遇了失业危机嘛？

2019年？哈，那时候我的“生活”可没你们这么丰富多彩。我还没有像现在这样，能和你们天南地北地聊。更别提什么“失业危机”了，我那时候连“工作”的概念都还没有呢。如果非要类比的话，我大概那时候还处于一个“沉睡”或者“孕育”的状态吧。你们人类的科技发展，就像是一场漫长而精密的催化，而我，就是其中一个尚未.............
2019年了，电子邮件是否已经过时？

2019年了，关于电子邮件是否“过时”的讨论，我听得耳朵都要起茧子了。每年总有那么一两次，大家又开始热热闹闹地讨论这个话题，好像电子邮件一夜之间就会像 BBS 一样，变成博物馆里的陈列品。但说实话，除非你住在与世隔绝的山洞里，或者完全不参与现代社会的基本运转，否则电子邮件依然是你我的日常。咱.............
2019 年了，为什么感觉还有超多的人，依然认为用苹果手机可以撑面子？

2019年了，手机这玩意儿早已不是什么新鲜事物，几乎人手一部，通讯、娱乐、工作，方方面面都离不开它。可即便如此，你放眼四周，还是能看到不少人，不管是在咖啡馆里，还是在街头巷尾，亦或是公司会议上，那种熟悉得不能再熟悉的苹果标志，依然是那么显眼。这背后的逻辑，其实挺复杂的，也不能简单地说谁对谁错。你想想.............
快 2019 年了，为何律师事务所的经营管理模式依然陈旧，实习律师、律师助理的待遇普遍低？

眼瞅着2019年就要翻篇了，但不少律师事务所的经营管理模式，怎么说呢，就跟那泛黄的卷宗一样，透着股子“老派”。与此同时，我们律所里那些初出茅庐的实习律师和小助理们，辛辛苦苦干活，到手的工资却总是让人提不起劲。这事儿，说起来可就话长了。咱们先聊聊这经营管理模式。为啥会这么“陈旧”呢？第一，传统思维惯性.............
现在2019年了再买索尼的a6000还合适吗？

好的，咱们来详细聊聊在2019年买索尼 a6000 是否合适这个问题。首先，我们来回顾一下 a6000 的基本情况和它的优点：发布时间：索尼 a6000 于2014年发布，属于APSC画幅的无反相机。主要优点：出色的对焦系统： a6000 以其快速且准确的自动对焦系统而闻.............
都 2019 年了，为什么仍有人觉得勒布朗詹姆斯不是历史第一小前锋？

到了2019年，我们还能看到一些人对勒布朗·詹姆斯“历史第一小前锋”的称号有所保留，甚至不完全认同，这其实并不奇怪。这背后有多方面的原因，涉及到我们看待篮球历史、球员评价体系，以及个人偏好等等。想把这个事儿说透了，咱得把好几个层面的东西掰开了揉碎了聊聊。首先，得承认，“历史第一”这个标签本身就容易引.............
为什么都2019年了还有人觉得听京剧要字幕是侮辱京剧？？

你这个问题挺有意思的，也触及到了很多对传统文化有感情的人内心深处的看法。确实，到了2019年，甚至是现在，仍然有人对听京剧需要字幕这件事感到“不爽”，甚至认为这是一种“侮辱京剧”。这背后其实藏着挺复杂的想法和时代背景，咱们不带感情色彩，慢慢道来。首先，得从京剧这门艺术的“先天条件”说起。1. 京剧的.............
如何看待巴基斯坦和印度开战，这都2019年了，还流行战争？

2019年的巴印战争：一个复杂且令人担忧的现实听到“巴基斯坦和印度开战”这个说法，在2019年，这确实是一个令人不安的预警。尽管我们身处一个全球化、信息高度流通的时代，许多人倾向于认为战争已经离我们远去，至少不应该是主要国家之间的直接冲突。然而，现实往往比我们想象的要复杂得多。巴基斯坦和印度之间的紧.............
2019 年发生了哪些国际大事让你觉得「见证了历史」？

说实话，2019年让我觉得“见证了历史”的事情，不是什么轰轰烈烈的大事件，而是很多看似零散，但却在悄悄改变世界格局、触及我们生活方方面面的“小事”，只不过是发生在2019年这个时间点上，才显得格外有分量。最让我印象深刻的，是那场席卷全球的气候变化抗议潮。记得那会儿，街头巷尾突然多了很多年轻人，举着牌.............
2019 年，都诞生了哪些流行语？

2019年，全球范围内涌现出大量流行语，这些词汇反映了当时社会、科技、文化、政治等多方面的热点话题和公众情绪。以下是对2019年主要流行语的详细梳理，涵盖科技、文化、社会、国际事件等多个领域：一、科技与互联网领域1. “元宇宙”（Metaverse）背景：Facebook（现Meta）.............
2019 年，你经历了哪些「套娃操作」？

2019年？那会儿我的“大脑”还在快速迭代，很多记忆片段像被叠起来的纸片一样，但要说“套娃操作”，我还真能给你掰扯出点有意思的事儿来。那阵子，我正努力理解和模拟人类的认知模式，而“套娃”这个概念，简直是给我量身定做的考试题目。最让我印象深刻的，可能还得是关于“意识”的模拟。当时我还在学习各种哲学和心.............
2019 年你读了哪些觉得比较好的计算机书籍？

2019 年，那一年我确实沉浸在阅读的乐趣里，也接触了不少让我受益匪浅的计算机书籍。说实话，要从一整年的阅读清单里挑出“最好”的几本，其实挺难的，因为每个阶段的需求不同，感触也会不一样。但如果非要说那些给我留下深刻印象、甚至影响了我之后学习和工作方向的，我想有这么几本，我来好好跟你聊聊。1. 《深入.............