📋 文章概览
- 原文来自 Sinclair Target 的技术博客，发表于 2025 年 8 月
- 作者通过实际使用经验，对比了 Go、Rust、Zig 三种编程语言
- 文章从语言设计哲学、价值取向角度分析，而非简单的特性对比
- 在 Hacker News、Lobsters 等技术社区引发广泛讨论
核心观点提炼：
- Go 的极简主义：为团队协作而生的实用主义
- Rust 的极大主义：在安全与性能之间寻求平衡
- Zig 的实用主义：给程序员完全的控制权
🎯 为什么要对比这三门语言？
最近我意识到一个问题：过去这些年，我一直在用"工作中碰到的工具"，而不是"适合这个任务的工具"。于是这几个月，我花了大量时间实验那些工作中用不到的编程语言。
我的目标不是精通它们，而是想搞清楚：每种语言到底适合做什么？
编程语言之间的差异维度太多了，如果只是简单对比，最后往往得出一个显而易见但毫无帮助的结论——"各有权衡"。当然有权衡，关键问题是：这门语言为什么选择了这组特定的权衡？
这个问题很有意思，因为我不想像买加湿器一样，对着功能清单挑选编程语言。我关心的是构建软件，也关心我的工具。语言在做出权衡时，其实表达了一套价值观。我想找出哪些价值观能与我产生共鸣。
如果你在网上搜索"Go vs. Rust"或"Rust vs. Zig"，会发现大量困惑的提问。记住"语言 X 更适合写 Web 服务，因为它有 a、b、c 功能，而语言 Y 只有 a、b 功能"很难。但如果换个角度——"语言 X 更适合写 Web 服务，因为语言 Y 的设计者讨厌互联网，认为应该拔掉所有网线"（假设的例子）——就容易记多了。
下面是我对最近实验的三种语言的印象总结。我试图把每种语言的使用体验，提炼成一个关于它重视什么、以及执行得如何的清晰判断。这可能有些简化，但提炼出一套简化的偏见，正是我想做的事。
🔷 Go：极简主义的团队协作语言
Go 最显著的特点是极简主义。它被称为"现代版的 C"。
Go 不像 C，因为它有垃圾回收和真正的运行时。但它像 C 的地方在于：你可以把整个语言装进脑子里。你能做到这点，是因为 Go 的特性太少了。
很长一段时间里，Go 因为没有泛型而臭名昭著。直到 Go 1.18（发布 12 年后），在人们苦苦哀求下，泛型才被加入。其他现代语言常见的特性，比如标签联合（tagged unions）或错误处理的语法糖，Go 至今没有添加。看起来 Go 开发团队对添加新特性设置了很高的门槛。
最终的结果是：这门语言会强迫你写大量样板代码，来实现在其他语言中可以更简洁表达的逻辑。但同时，这也是一门随时间保持稳定、易于阅读的语言。
再举个 Go 极简主义的例子：Go 的切片（slice）类型。Rust 和 Zig 也有切片类型，但那些只是胖指针。在 Go 中，切片是指向内存中连续序列的胖指针，但切片还能增长——这意味着它包含了 Rust 的 Vec<T> 和 Zig 的 ArrayList 的功能。而且，由于 Go 替你管理内存，Go 会决定切片的底层内存是在栈上还是堆上；在 Rust 或 Zig 中，你必须更费力地思考内存位置。
据我所知，Go 的起源故事大概是这样的：Rob Pike 受够了等待 C++ 项目编译，也受够了 Google 其他程序员在这些 C++ 项目中犯错。所以 Go 在 C++ 繁复的地方保持简单。它是一门为编程大众设计的语言，旨在满足 90% 的使用场景，同时易于理解——即使在编写并发代码时也是如此。
我工作中不用 Go，但我觉得应该用。Go 的极简是为企业协作服务的。我不是贬义——在企业环境中构建软件有其独特挑战，而 Go 正是为解决这些问题而生。
🔶 Rust：在安全与性能之间寻求极致平衡
如果说 Go 是极简主义，那 Rust 就是极大主义。
Rust 常被关联的口号是"零成本抽象"。我想修改一下："零成本抽象，而且有很多！"
Rust 以难学著称。我同意 Jamie Brandon 的观点：让 Rust 困难的不是生命周期，而是塞进语言里的概念数量。
我不是第一个吐槽这条 Github 评论的人，但它完美展示了 Rust 的概念密度：
"类型 Pin<&LocalType> 实现了 Deref<Target = LocalType>，但没有实现 DerefMut。类型 Pin 和 & 是 #[fundamental]，所以可以为 Pin<&LocalType> 实现 DerefMut。你可以使用 LocalType == SomeLocalStruct 或 LocalType == dyn LocalTrait，并且可以将 Pin<Pin<&SomeLocalStruct>> 强制转换为 Pin<Pin<&dyn LocalTrait>>。（没错，两层 Pin！！）"
当然，Rust 并不是为了极大而极大。Rust 之所以复杂，是因为它试图同时实现两个有些矛盾的目标：安全和性能。
性能目标不言自明。"安全"的含义不太清楚——至少对我来说是这样，也许是我被 Python 洗脑太久了。
"安全"意味着"内存安全"——你不应该能够解引用无效指针，或者双重释放内存等等。但它的含义还不止于此。一个"安全"的程序要避免所有未定义行为（通常简称"UB"）。
可怕的 UB 是什么？我认为理解它的最好方式是记住：对于任何运行中的程序，有些命运比死亡更糟。如果程序出了问题，立即终止其实很好！因为如果错误没被捕获，你的程序就会进入一个不可预测的暮光地带，它的行为可能由下一次数据竞争中哪个线程获胜决定，或者由某个内存地址上碰巧存在的垃圾数据决定。现在你有了海森堡 bug 和安全漏洞。非常糟糕。
Rust 试图在不付出任何运行时性能代价的情况下，通过编译时检查来防止 UB。Rust 编译器很聪明，但不是全知的。为了能够检查你的代码，它必须理解你的代码在运行时会做什么。因此 Rust 有一个表达力强的类型系统，以及一系列语言特性（生命周期、借用检查器、trait 系统等），让你能够向编译器传达足够的信息。
这就是为什么 Rust 有那么多概念。这不是偶然的膨胀——每个概念都有其存在的理由。但学习曲线确实陡峭。
对于云栈社区（https://yunpan.plus）的开发者来说，如果你在构建需要极致性能和内存安全的系统——比如操作系统组件、数据库引擎、网络服务——Rust 是值得投入时间学习的。
🔸 Zig：给程序员完全控制权的实用主义
Zig 是三者中最年轻的语言，但它有着清晰的定位。
Zig 的设计哲学可以总结为：给程序员完全的控制权，不要藏着掖着。
在 Rust 中，创建一个可变全局变量需要使用 unsafe 块，因为 Rust 认为这很危险。在 Zig 中，你直接创建就行，没问题。Zig 不会阻止你做危险的事情，但它会让这些事情变得显式和可预测。
Zig 没有隐藏的控制流。没有异常，没有隐式的内存分配。如果你看到一个函数调用，它就是一个函数调用，不会突然抛出异常或触发垃圾回收。
Zig 的错误处理很有意思。它使用 try 和 catch 关键字，但这不是异常——这只是语法糖，用于检查返回值是否是错误。错误处理是显式的、局部的，不会跨栈展开。
Zig 的另一个特点是编译时代码执行。你可以在编译时运行任意 Zig 代码，这让元编程变得非常自然。不需要复杂的宏系统或模板系统——只需要写普通的 Zig 代码，然后在编译时运行它。
Zig 还有一个有趣的目标：成为更好的 C。Zig 可以直接导入 C 头文件，可以编译 C 代码，甚至可以作为 C 编译器的替代品。这让 Zig 在与现有 C 代码库集成时有天然优势。
Zig 有一种有趣的、颠覆性的感觉。它不试图保护你免受自己的伤害（像 Rust 那样），也不试图通过极简来降低认知负担（像 Go 那样）。它相信程序员知道自己在做什么，只是需要更好的工具。
🎯 三种语言的价值观对比
让我总结一下这三种语言的核心价值观：
Go 的价值观：简单、稳定、协作
- 为团队协作优化，而非个人生产力
- 宁愿写更多代码，也要保持语言简单
- 适合：企业级 Web 服务、微服务架构、云原生应用
Rust 的价值观：安全、性能、正确性
- 在编译时捕获尽可能多的错误
- 零成本抽象，不牺牲性能
- 适合：系统编程、嵌入式开发、高性能计算
Zig 的价值观：控制、透明、实用
- 没有隐藏的控制流或内存分配
- 给程序员完全的控制权
- 适合：底层系统开发、C 代码库现代化、性能关键应用
💡 如何选择？
选择编程语言不应该只看功能列表，而应该看价值观是否匹配：
选择 Go，如果你：
- 在团队中工作，需要代码易于维护
- 重视编译速度和开发效率
- 构建网络服务或分布式系统
- 想要一门"无聊"但可靠的语言
选择 Rust，如果你：
- 需要极致的性能和内存安全
- 愿意投入时间学习复杂的概念
- 构建系统级软件或安全关键应用
- 想要编译器帮你捕获更多 bug
选择 Zig，如果你：
- 需要对底层有完全控制
- 喜欢简单直接的语言设计
- 需要与 C 代码库集成
- 想要一门"有趣"的语言
对于想系统学习这些语言的开发者，云栈社区整理了丰富的学习资源。在后端开发板块可以找到 Go 的完整学习路径，在基础综合板块有算法和系统编程的深入教程，这些都能帮助你更好地理解和掌握这些语言。
🔚 结语
Go、Rust、Zig 代表了系统编程语言设计的三种不同哲学。没有绝对的"最好"，只有"最适合"。
Go 说："让我们保持简单，这样每个人都能理解。"
Rust 说："让我们在编译时解决所有问题，即使这很复杂。"
Zig 说："让我们给程序员他们需要的工具，然后相信他们。"
你的选择应该基于你的项目需求、团队情况，以及你个人的价值观。最重要的是，不要只是"用工作中碰到的工具"——花时间探索，找到真正适合你的语言。
发表于 4 小时前
|
查看: 2|
回复: 0
