C - Tony Bai

本文永久链接 – https://tonybai.com/2025/07/25/go-vs-rust-vs-cpp-in-complexity)

大家好，我是Tony Bai。

最近，一张关于编程语言规范词数统计的图表，在技术圈广为流传。它以一种极其直观、甚至有些残酷的方式，将不同语言的复杂性摆在了我们面前。

在这张图上，我们看到了惊人的差异：

C++: 以超过 80 万词的规范长度，一骑绝尘，成为当之无愧的“巨无霸”。
C# 和 Java: 分别以约 40 万和 25 万词紧随其后，是功能丰富的“航空母舰”。
Go: 规范仅约 5 万词，与以简洁著称的 C (约 5.5 万词) 处于同一量级。

这张图不仅仅是一个有趣的谈资。语言规范的长度，是衡量一门语言复杂度的最客观指标之一。 它直接决定了这门语言的学习曲线、认知负荷，以及整个生态的风格。

今天，我们就以这张图为起点，深入探讨三门备受关注的系统级语言——Go、Rust 和 C++——它们各自代表的三种截然不同的“复杂性”，以及这些“复杂性”在 AI 时代意味着什么。

注：Go之所以被最初定位为系统级编程语言，是因为其设计之初便承载了构建高效、可靠系统级软件的愿景，旨在解决多核、网络化机器时代下大型代码库的开发痛点。然而，其内置的垃圾回收机制和相对较大的运行时，以及它在网络服务、云计算、微服务等应用层领域取得的显著成功和广泛应用，逐渐改变了开发者对其的普遍认知，使得今天多数开发者不再将其归类为传统的、如C/C++般直接操作硬件的系统级编程语言。

“广度”的复杂性：C++ 的特性博物馆

C++ 的冗长规范，源于其“广度”上的复杂性。它像一个不断扩建的“特性博物馆”，收藏了自上世纪 80 年代以来的几乎所有编程范式。从 C with Classes，到面向对象，再到泛型元编程，再到现代的函数式风格，C++ 不断地累加新特性，却很少移除旧的。

这种复杂性的特点是：

特性极其繁多： 多重继承、模板、操作符重载、右值引用… 你永远无法完全掌握它。
选择极其自由： 对于同一个问题，你可能有十种不同的实现方式，每一种都有其微妙的优劣。

这导致的结果是，没有人能成为一个“纯粹的 C++ 开发者”，大家通常都只是某个 C++“安全子集”的专家。团队协作的巨大成本，就耗费在统一这个“子集”上。Google 著名的 C++ Style Guide，其本质就是一份“C++ 禁用特性列表”。

“深度”的复杂性：Rust 的陡峭山峰

再看 Rust。它的规范词数（约 10 万词）远比 C++ 短小，但几乎所有人都承认，Rust 的学习曲线极其陡峭。

这是因为它代表了另一种“深度”上的复杂性。Rust 的复杂性并非源于海量的特性，而是集中在少数几个强大、深刻且深度交织的核心概念上：

所有权 (Ownership)
生命周期 (Lifetimes)
借用检查器 (Borrow Checker)

你不需要学习一百个小工具，但你必须彻底攀登这几座陡峭的山峰，才能真正驾驭这门语言。它的挑战不在于“知道什么”，而在于“深刻理解”。你需要在脑海中构建一个全新的心智模型，时刻与编译器进行一场关于内存安全的“博弈”。

“组合”的复杂性：Go 的乐高世界

最后，我们来看 Go。它的规范如此之短，是因为它从设计之初就选择了第三条路：将“复杂性”从语言本身，转移到开发者身上。

这里所说的Go的复杂性，是“组合”的复杂性。它为你提供的不是一套功能完备的“瑞士军刀”，而是一盒简单、正交、数量有限的“乐高积木”：

简单的类型系统（没有类和继承）
只有一个循环结构 (for)
清晰的接口（隐式实现）
强大的并发原语 (goroutine 和 channel)
… …

Go 语言本身是极其简单的，一个有经验的开发者可以在一周内掌握其全部语法。真正的挑战在于，你如何用这些有限的、简单的积木，去创造性地组合，以解决现实世界中的复杂问题。

Go 的设计哲学相信，通过组合这些简单的工具，你足以构建出任何复杂的系统。它把对创造力的要求还给了开发者，而不是将其隐藏在语言的“语法糖”和“黑魔法”之下。

AI 时代的新视角：哪种复杂性对 AI 更“友好”？

这场关于复杂性的讨论，在 AI 编程助手日益普及的今天，有了一层全新的意义。我们可以把语言规范的长度，看作是教一个 AI“学生”这门语言的“教科书厚度”。

教 AI 写 C++： 就像给它一本大英百科全书。它能学会无数语法，但面对复杂的特性交互和未定义行为时，极易产生“幻觉”，生成看似正确但存在隐蔽 bug 的代码。审查这样的代码是一场噩梦。
教 AI 写 Rust： 就像教它下围棋。它能学会规则，但很难掌握其深奥的战略（生命周期）。它生成的代码或许能通过编译，但可能是为了“讨好”编译器而写出的、极其扭曲和不符合人类直觉的代码。
教 AI 写 Go： 就像给它一本清晰、简洁的“小红书”。规则少、边界清晰、没有“魔法”。AI 生成的代码不仅更可预测、更符合语言的最佳实践，最重要的是——它对人类审查者极其友好。

在 AI 时代，我们开发者的工作重心正在从“写代码”，更多地转向“审查和指导 AI 写代码”。一门简单的、拥有短小精悍规范的语言，为我们和 AI 之间提供了一个共同的、易于理解的交流基础。

小结：简洁，一种面向未来的选择

回到最初的图表，它揭示了三种不同的设计哲学：

C++： “我给你一切，你自己想办法管好。”
Rust： “我会替你管好一切，但你必须先理解我的全部规则。”
Go： “我只给你几样最强大的工具，剩下的，我相信你的创造力。”

Go 的简洁，不是功能的匮乏，而是一种深思熟虑的、面向未来的战略选择。它不仅降低了人类开发者的认知负荷，更在不经意间，为即将到来的人机协作编程时代，铺平了道路。

因为当你的“同事”是一个 AI 时，一门简单、可预测、易于审查的语言，将是你最有价值的资产。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/07/22/cedardb-choose-cpp-rather-than-rust

大家好，我是Tony Bai。

近年来，Rust 语言无疑是技术圈最炙手可热的明星。它以“内存安全”的核心承诺，向统治了系统编程领域数十年的 C++ 发起了强有力的挑战。无数文章和布道者都在宣扬一个近乎“神话”的观点：用 Rust，你就能告别段错误和内存泄漏。

然而，就在这股“Rust 替换一切”的热潮中，一个来自行业核心的声音，给我带来了深深的思考。

Moritz Sichert，高性能数据库 CedarDB 的联合创始人兼 CEO，最近发表了一个“反直觉”的观点：

“Rust 是一门很棒的语言，我真的很喜欢用它。然而，当涉及到数据库系统时，我仍然会选择 C++ 而不是 Rust。”

一个数据库 CEO，在一个对数据安全和系统稳定性要求极致的领域，放弃了以“安全”著称的 Rust，转而拥抱充满了“历史遗留问题”的 C++。这究竟是为什么？

这并非一次简单的“厚此薄彼”，而是一场关于工程现实与语言哲学之间深刻权衡的精彩案例。

理论安全 vs 工程现实：unsafe 的“逃生舱口”

Moritz 首先承认了 Rust 的优点：理论上，Rust 通过其所有权系统和借用检查器，提供了远超 C++ 的默认安全性。这正是大家喜爱 Rust 的原因。

但问题在于，像 CedarDB 这样的高性能数据库，其开发工作远不止是处理业务逻辑。它需要深入到硬件的毛细血管中，榨干每一滴性能。这意味着：

使用大量底层的 CPU 特性。
实现复杂的侵入式数据结构。
进行带有验证的、乐观且激进的内存访问。

在这些场景下，Rust 的安全检查反而成了“束缚”。为了完成任务，你必须使用 Rust 提供的“逃生舱口”——unsafe 关键字。

而 Moritz 抛出的重磅炸弹正在于此：

“一旦你在 Rust 中写下 unsafe 代码，所有的赌注都将失效。在 unsafe 代码中，你遇到未定义行为（UB, Undefined Bahavior）的风险，甚至比在 C++ 中还要高。”

unsafe Rust：一个更危险的“黑暗森林”？

这个论断足以颠覆许多人的认知。unsafe Rust 怎么会比 C++ 还危险？

关键在于理解 unsafe 到底意味着什么。它不是简单地“关闭”安全检查，而是程序员向编译器立下了一个契约：“编译器，请相信我，接下来的这段代码，我将手动保证它完全遵守 Rust 的内存模型和别名规则（Aliasing Rules）。”

这正是问题的核心所在。
* C++ 的危险是“已知的”：C++ 就像一片广阔的雷区，但经过几十年的探索，老兵们已经绘制出了详细的“排雷图”。虽然处处是坑，但如何避免、如何调试，已经积累了大量的工程实践和模式。
* unsafe Rust 的危险是“微妙的”：unsafe 区域就像一个“黑暗森林”，你不仅要面对 C++ 程序员熟悉的裸指针、内存布局等问题，更要命的是，你还必须手动维护 Rust 那套比 C++ 更为严格的别名规则（例如，在任何给定时间，你只能有一个可变引用 &mut T，或者任意数量的不可变引用 &T，但不能两者都有）。

对于一位经验丰富的 C++ 开发者而言，在 unsafe 块里很容易不自觉地写出 C++ 风格的指针操作，却无意中违反了 Rust 的核心不变量，从而触发 UB。这种“新规则”下的自由，反而成了一个更容易跌落的陷阱。

Moritz 的观点是：在一个必须大量使用 unsafe 的项目中，与其在一个受严格规则约束的环境里“戴着镣铐跳舞”，不如直接选择那个虽然危险、但规则更为人熟知且自由度更高的 C++。

聊聊 Go：一种不同的安全哲学

那么，聊了这么多 Rust 和 C++，我们作为 Gopher 能从中得到什么启发呢？这恰好能让我们更深刻地理解 Go 的设计取舍。

Go 语言同样有一个 unsafe 包。但与 Rust 的设计哲学截然不同。

Rust 的 unsafe 是语言的一等公民，是其系统编程能力的重要组成部分，是为了实现“零成本抽象”而设计的必要工具。

而 Go 的 unsafe，从其文档的第一句话起，就在极力地“劝退”你：

“任何使用了 unsafe 包的程序都可能在未来 Go 语言版本中无法移植……使用 unsafe 的代码，其安全性需要程序员手动保证，我们不建议使用。”

在 Go 的世界里，unsafe 更像一个被严格限制的“后门”，而非一个功能特性。它的存在主要是为了实现标准库（如 runtime、sync），或在极少数与 C 库交互、进行极致性能微调的场景下使用。

我们可以这样总结三者的哲学：
* C++：默认给予你全部的权力与危险，安全是你的责任。
* Rust：默认提供极致的安全，但给你一个 unsafe 的选项，让你在立下严格契约为前提下重获权力。
* Go：默认通过 GC 和简单的内存模型提供高度的工程安全与效率，unsafe 是一个官方不鼓励、非标准的“应急方案”。

Go 的选择是，在绝大多数场景下，宁愿牺牲掉那部分通过复杂手动内存管理换来的极限性能，也要保证语言模型的简单性和大规模团队协作的工程效率与安全。