Rust - Tony Bai

本文永久链接 – https://tonybai.com/2025/04/29/hard-truths-before-switching-to-go

大家好，我是Tony Bai。

Go 语言近年来势头强劲，凭借其简洁、高效、出色的并发能力和工具链，吸引了大量开发者投身其中。甚至连TypeScript 团队也宣布将其编译器和工具集迁移到 Go，以提升性能。这无疑是对 Go 的巨大认可。

然而，正如一位拥有超过 15 年经验（主要使用 Java/Kotlin/TypeScript）、并在过去一年深度使用 Go 的开发者（以下简称“视频作者”）在其分享的油管视频中提到的那样，尽管 Go 非常出色，但光环之下并非没有阴影。在投入实际项目，特别是构建一些非同小可的东西之后，会发现 Go 的一些设计决策有利有弊，有些“简洁”的背后隐藏着需要注意的“真相”。

这位作者认为，计划学习或在下一个项目中使用 Go 的开发者，都应该了解这些潜在的“硬伤”或权衡。以下是他总结的、在转向 Go 之前你需要真正了解的五件事，主要转述自他的分享：

真相一：简洁的表象与表达力的代价

Go 最大的卖点之一是它的简洁性。表面上看，它确实如此。但视频作者认为，一旦你超越了教程的范畴，就会发现这种简洁很多时候是以牺牲表达力为代价的。

隐藏而非消除复杂性？
- 比如，Go 有 while 循环的功能，却没有 while 关键字，你需要用 for 循环省略条件来实现。
- 可见性（公有/私有）由首字母大小写决定，而非明确的 public/private 关键字。这虽然简洁，但在重构时容易忽略，更改大小写可能在没有编译器警告的情况下破坏 API。
- 枚举（Enum）也没有原生支持，而是通过 const 和 iota 的变通方法实现。

在作者看来，Go 似乎不惜一切代价追求简单和极简的外观，有时这意味着隐藏了复杂性，而不是真正消除了它。

真相二：多返回值并非“一等公民”

从函数返回多个值是 Go 的一个特色，尤其在错误处理上，(value, error) 模式初看很优雅，没有异常、没有 try-catch。

但视频作者指出的根本问题是：Go 中的多返回值实际上不是元组 (Tuples) 或一等公民 (First-class values)。

你不能将它们整体存入一个变量。
你不能将它们放入切片 (Slice)。
你不能通过通道 (Channel) 发送它们。
你无法用泛型 (Generics) 对它们进行抽象。

这意味着，当需要处理一系列返回 (value, error) 的结果时（例如并发执行多个操作后收集），你被迫创建一个自定义的结构体 (struct) 类型来将这些值打包在一起。作者认为，这种为了传递数据而创建额外类型的做法，正是他当年想要逃离 Java 时所厌恶的不必要的样板代码 (boilerplate code)。

真相三：错误处理极其冗长

Go 的错误处理方式，特别是 if err != nil { return …, err } 的模式，是开发者初次接触 Go 时最常见的抱怨点之一。

视频作者坦言，在 Go 中管理错误是极其冗长 (extremely verbose) 的。

虽然 Go 官方称之为“显式错误处理”，并由 Rob Pike 等创造者辩护其提高了可读性、保持了控制流清晰，但与其他语言（如 Rust）提供的解决方案相比，确实显得繁琐。
社区曾尝试改进，甚至有过添加内置 try 机制的提案，但最终因担心破坏 Go 的简洁性而被否决。

真相四：拥抱组合，但需适应思维转变

Go 的创造者们反对像 Java 那样复杂的继承体系，认为继承容易导致脆弱、混乱的代码库。因此，Go 的官方哲学是避免继承，倾向于组合 (composition)。

Go 中的嵌入 (Embedding) 看起来有点像继承，但作者强调它完全是另一回事。
这种方法确实在很多方面让 Go 代码更简单、更可预测，但它意味着来自传统面向对象编程 (OOP) 语言的开发者需要调整他们的思维方式。
Go 并非试图成为部分 OOP 语言，而是提供了一种不同的代码组织方法，用清晰性和简洁性换取了继承的部分灵活性。

真相五：泛型设计，简洁性优先于灵活性

Go 最初没有泛型，这个决定限制了语言十多年。泛型最终在 2022 年 (Go 1.18) 引入，但其设计仍然体现了 Go 简洁性优于灵活性的哲学。

Go 不支持函数或运算符重载 (overloading)。
其类型约束系统虽然对许多用例足够强大，但并未提供其他语言中 traits 或 type classes 的全部表达能力。

这依然符合 Go 优先考虑清晰度和可读性，而非极致表达能力的基本理念。

结语：睁大眼睛看Go

视频作者最后总结，如果你期望 Go 能提供像具有大量语法糖的高级语言那样的开发体验，你会感到失望。

但如果你在寻找一门快速、可靠、务实、不碍事且编译飞快的语言，Go可能就是最适合你的工具。

关键在于，要“睁大眼睛去看待它 (go in with your eyes open)”。因为，仅仅通过看视频或教程喜欢上一门语言，和在维护一个有真实用户、边缘情况的真实世界项目后仍然喜欢它，这两者之间可能存在巨大的差别。理解 Go 的这些设计选择和它所带来的权衡，对于做出明智的技术决策至关重要。

希望转述的这些来自一线开发者的“硬核”观察，能帮助大家更全面地认识 Go。

你对 Go 的这些特性有什么实际体验或看法？欢迎在评论区留言讨论！

视频地址：https://www.youtube.com/watch?v=UEU4SzBjqrc

系统学习，夯实基础

想要更系统、更深入地理解 Go 语言，从基础语法、并发编程到设计哲学和工程实践，全面掌握这门高效的语言吗？欢迎订阅我在极客时间的专栏 《Go 语言第一课》。那里有更结构化的知识体系和详尽的讲解，助你打下坚实的 Go 语言基础，从容应对真实世界的挑战。

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

本文永久链接 – https://tonybai.com/2025/04/17/go-is-badly-designed

大家好，我是Tony Bai。

今天刷X (前Twitter) 的时候，看到Golang Insiders社区下面这条推文，真是差点扑哧一声笑出来，感觉说得太形象了，必须分享给大家：

这位叫Lyes的开发者回应 “Go is badly designed” (Go 语言设计得很糟糕) 的说法，他打了个比方：

这让我想起了我的高中物理老师，我们当时都恨他，因为他从不‘放水’简化物理知识。课难、考试难，大部分人在他手下分数都不高，所以他自然成了‘坏老师’。

Go 语言就有点像他。它从不‘放水’，直面问题。你可以很快用它变得高效，写出远比用 Python 或 JavaScript 写得更好的软件。

但你也得知道，这门语言不会‘溺爱’你。当你的服务器因为一个 nil map 或其他新手常犯的错误而 panic 时，别生气。

不像 Rust，Go 的编译器不会在你编程生涯的每一刻都‘牵着你的手’。它会给你足够的方向让你知道该往哪走，满足你 80% 的需求，同时仍然保持你的生产力。

怎么样？看完这段话，是不是像极了我们初学Go时，被nil pointer dereference 或 index out of range 当头棒喝的瞬间？ 像极了我们当年一边抱怨物理老师太严格、考试太变态，一边又不得不硬着头皮去啃那些公式和定理的样子？

Lyes 的这个比喻，可以说精准地戳中了 Go 语言的一些核心特质，也解释了为什么关于“Go是否设计糟糕”的争论从未停止。咱们今天就借着这个“物理老师”的比喻，好好聊聊Go的“坏脾气”和它背后的设计哲学。

那个从不“放水”的“严格老师”

Lyes 说 Go 不会 “dumb down anything(简化任何事物，去除复杂性)”，这太对了。Go语言的设计哲学里，“简洁”（Simplicity） 是核心原则之一，但这不代表“简单化”到隐藏问题的程度。相反，它选择直面问题：

显式的错误处理 (if err != nil)：不像某些语言用try-catch将错误“藏”起来，Go强迫你几乎在每次可能出错的操作后都检查错误。这很“烦”，但它逼着你思考每一步潜在的风险，就像物理老师逼着你弄懂每个公式的推导过程。
直白的运行时Panic：当你对一个 nil 的 map 或 slice 进行操作时，Go 不会帮你“优雅地”处理，而是直接给你一个运行时 panic，程序崩溃。这很“粗暴”，但它用最直接的方式告诉你：“同学，你这里犯了个基础错误，赶紧改！” 这不就是物理老师发现你基本概念没搞懂时，直接点名批评，让你印象深刻吗？
没有“溺爱”的语法糖：相比一些现代语言，Go 的语法糖相对较少。它没有泛滥的操作符重载，没有复杂的隐式转换。很多事情需要你明确地写出来。这让代码有时候显得“啰嗦”，但大大降低了阅读和理解他人代码时的歧义，保证了大规模团队协作的效率。就像物理老师坚持用标准的符号和单位，不允许自创“简写”，是为了保证科学的严谨性。

“坏老师”真的“坏”吗？—— 严格背后的价值

我们当年可能都偷偷抱怨过物理老师不近人情，但多年后回想，是不是反而感谢他的严格，才让我们打下了坚实的基础？Go 语言的“严格”同样如此：

逼你养成好习惯：被 nil panic 搞崩溃几次后，你自然就学会了在使用 map/slice/pointer 前做检查，学会了初始化，学会了更严谨地思考边界条件。这种被“教训”出来的习惯，最终会融入你的编程血液，让你写出更健壮、更可靠的代码。这比那些“温柔”地帮你掩盖了问题，直到生产环境才爆发出更大危机的语言，是不是长期来看更负责任？
简单直白，易于掌握核心：虽然会“当头棒喝”，但Go的核心概念相对较少，语法简洁。一旦你掌握了它的规则（比如错误处理模式、接口哲学、goroutine的使用），就能快速上手，并且写出的代码风格差异不会太大，易于团队维护。它不像某些语言，特性繁多，学习曲线陡峭，精通需要漫长时间。Go就像物理老师划定的核心考点，虽然难，但范围明确，努力就有回报。
效率与务实：给你“80%的指引”：Lyes 提到了Go与Rust的对比，说Go不会“全程牵手”。这正是Go的务实之处。它在编译速度、开发效率和运行时安全之间做了一个取舍。它通过快速编译、垃圾回收、简洁的并发模型，让你能高效地构建系统，满足大部分（比如 80%）场景的需求。它相信开发者是成年人，应该为自己的代码负责，而不是让编译器承担所有检查的重任。这就像物理老师教会你核心原理和解题方法，但不会一步步带着你做完所有练习题，他相信你能举一反三，独立解决问题。

不是“设计糟糕”，而是哲学不同

所以，“Go is badly designed” 吗？

与其说是“糟糕”，不如说是设计哲学和目标受众的不同。

如果你期望一门语言能像 Rust 那样，在编译期就为你消除几乎所有内存安全和并发风险，愿意为此付出更陡峭的学习曲线和更长的编译时间，那么 Go 可能确实“不够好”。
但如果你追求的是快速构建、高效部署、简单可靠、易于维护的大型后端系统，能接受在运行时处理一些本可避免的错误（并通过良好的实践和工具来减少它们），那么Go的设计哲学可能恰恰是它的优点。

Go 就像那位严格的物理老师，他可能不会让你在学习过程中时刻感到“舒适”，甚至会让你经历挫败和“阵痛”。但他目标明确，方法直接，逼着你打好基础，养成严谨的习惯，最终让你能够独立、高效地解决实际问题。

那么，你怎么看？

你觉得Go语言像不像你当年“恨过”的某位老师？
你第一次遇到 nil panic 时是什么感受？是觉得Go设计糟糕，还是反思自己代码的问题？
你更喜欢 Go 这种“给你方向，但不全程牵手”的方式，还是 Rust 那种“无微不至的保护”？

欢迎在评论区留下你的看法，分享你和 Go “相爱相杀”的故事！

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」，掌握 AI 时代新技能。
星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：