标签 Java 下的文章

Go的简洁神话?转Go前你需要知道的5个“真相”

本文永久链接 – 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 语言基础,从容应对真实世界的挑战。

img{512x368}


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

go-yaml归档背后:Go开源生态的“脆弱”与“韧性”,我们该如何看待?

本文永久链接 – https://tonybai.com/2025/04/28/go-ecosystem

大家好,我是Tony Bai。

最近,Go社区里的一则消息引发了不少关注和讨论:广受欢迎的 go-yaml 库作者 Gustavo Niemeyer 宣布将项目正式标记为“归档(archived)”。这不仅让很多依赖该库的项目需要考虑迁移,也恰好触动了许多 Gopher 心中的一根弦。

就像我的知识星球“Go & AI 精进营”里的星友 Howe 所提出的那个精彩问题一样:

“白老师…其实会发现,很多 Go 开源工具是没有持续更新维护的好像,不像 Java 那种,有一些框架甚至会有专门的组织去维护,比如 Spring,所以从这点来看,Go 的生态发展就比较担忧了,不知道会不会多虑了…”

go-yaml 的归档,似乎成了这个担忧的一个现实注脚。一个维护了十多年、被广泛使用的基础库,说停就停了,这是否预示着 Go 的开源生态存在系统性的脆弱?我们是否真的应该为此感到焦虑?

在下结论之前,我们不妨先看看 go-yaml 作者 Gustavo 本人的说明,这其中透露的信息远比“停止维护”四个字要丰富得多:

“这是我最早的 Go 项目之一…维护了十多年…可惜的是…个人和工作空闲时间都减少了…我原本希望通过将其转移到资源更丰富的专业团队…但最终也没能如愿…我也不能直接把维护工作‘交给’某个人或一个小团队,因为项目很可能会再次陷入无人维护、不稳定甚至被滥用的状态。…很抱歉。”

Gustavo 的话语中,我们读到的不是草率的放弃,而是一个资深开源贡献者长达十年的坚持、后期的力不从心、以及对项目质量和用户负责任的审慎态度。这恰恰揭示了许多 Go 开源项目(乃至整个开源世界)的一个普遍现实:大量项目是由个人开发者或小团队利用业余时间驱动的,他们的热情和精力是项目持续发展的关键,但也可能成为单点故障。

在深入探讨之前,我们首先要向 go-yaml 的作者 Gustavo Niemeyer 致以诚挚的感谢。他凭借个人的热情和努力,将这个项目从 2010 年的圣诞假期启动,并坚持维护了超过十年之久,为 Go 社区贡献了一个极其重要的基础库。我们理解并尊重他因个人时间精力变化而做出归档的决定。需要明确的是,本文无意指摘这一事件本身,而是希望借此契机,与大家一同审视和思考 Go 开源生态系统的韧性与我们应如何看待其发展模式。

Go 生态模式 vs Java (Spring) 模式:不同而非优劣

Howe 的问题提到了 Java Spring,这是一个很好的对比参照。以 Spring 为代表的许多 Java 核心框架,背后往往有强大的商业公司或成熟的基金会提供组织化保障。这种模式无疑提供了更高的确定性资源投入,让使用者更有“安全感”。

相比之下,Go 的生态呈现出不同的特点:

  1. 强大的标准库 “自带电池”: Go 从设计之初就内置了极其丰富且高质量的标准库。
  2. 社区驱动,“小而美”哲学: Go 社区倾向于构建更小、更专注、职责单一的库。
  3. 公司开源与社区贡献并存: Go 生态中,既有大量个人维护的优秀项目,也有 Google、HashiCorp、Uber 等公司开源并积极维护的核心库。
  4. Go Modules 的作用: Go Modules 让依赖管理变得清晰,发现、评估和替换依赖库也相对容易。

go-yaml 事件:是“脆弱”的证明,还是“韧性”的体现?

go-yaml 的归档确实暴露了依赖个人维护者带来的风险(“脆弱”)。但我们更应该看到的是生态系统的应对和演化(“韧性”):

  • 现实更复杂 – K8s 的硬分叉: 近期 Kubernetes 社区关于 kubernetes-sigs/yaml 的讨论 (Issue #129) 揭示了一个更深层的事实。原来,Kubernetes 社区早在 2023 年就已经对 go-yaml 的 v2 和 v3 版本进行了硬分叉 (hard fork),并将其纳入 sigs.k8s.io/yaml 进行自主维护。他们这样做是为了获得完全的掌控力、保障稳定性,并确保其行为符合 Kubernetes 对 JSON 兼容性的特定需求。这表明,像 Kubernetes 这样的重量级玩家,在核心依赖面临不确定性或不完全满足需求时,会选择更“硬核”的方式来确保自身生态的稳定,而不是简单跟随上游的推荐。这既是生态韧性(有能力采取极端措施自我保护)的体现,也增加了生态的复杂性
  • 替代品与多元选择: 上述 K8s 的 Issue 中也提到了另一个正在崛起的 YAML 库 goccy/go-yaml,并指出 Kubernetes 之外的 Go 生态似乎正向其靠拢。这进一步说明,Go 生态并非只有一条路可走,而是充满了动态的选择和竞争。当一个库出现维护问题或不能满足所有需求时,社区往往会涌现出不同的解决方案。
  • 社区的自愈能力: 无论是官方推荐的继任者、重量级玩家的硬分叉,还是社区涌现的新替代品,都展示了 Go 生态在面临挑战时的自我修复和演化能力。Go Modules 在这种多元选择并存的情况下,为管理依赖提供了基础工具。

与此同时,2023年Go官方团队曾对于“是否应将encoding/yaml加入标准库”的讨论(可见于GitHub Issue #61023)也为我们理解这一现状提供了官方视角。 尽管 YAML 在 Go 生态(尤其是 K8s、Helm 等领域)中应用极为广泛,且社区多次呼吁将其纳入标准库,但 Go 核心团队(包括 Russ Cox 本人)最终以 “不可行 (infeasible)” 拒绝了该提议。

拒绝的核心原因并非不认可 YAML 的重要性,而是其内在的巨大复杂性。 RSC 指出,YAML 规范远比 JSON 甚至 XML 复杂得多,实现一个完整、健壮且能长期维护的 YAML 解析器超出了当前 Go 团队的实际能力范围。尝试定义和实现一个“官方子集”同样困难重重,且可能导致更多的兼容性问题(encoding/xml 的前车之鉴也被提及)。

更关键的是,Go 团队明确认可并推荐使用 gopkg.in/yaml.v3(即go-yaml/yaml) 作为 Go 生态中事实上的标准 YAML 库。 这再次印证了 Go 生态的韧性不仅体现在硬分叉或新库涌现上,也体现在社区能够围绕一个高质量的第三方库(即便它依赖个人维护者)形成广泛共识,并由官方背书推荐。这种模式,虽然不如标准库那样“保险”,但也是 Go 生态现阶段运作的重要特征。

我们是否多虑了?如何获得“生态安全感”?

担忧是合理的,但过度焦虑则不必。Go 在云原生等领域的成功,本身就依赖于其生态系统的支撑。关键在于,作为 Gopher,我们该如何在这种生态模式下获得“安全感”?

  1. 尽职调查,深度了解: 在选择依赖时,需要更深入地了解:
    • 它实际依赖的是哪个底层实现?(尤其是在有包装库或 fork 的情况下,如 sigs.k8s.io/yaml)
    • 使用 go mod graph, go mod why 等工具,厘清直接和间接依赖。意识到像 K8s 生态那样,即使切换了直接依赖,间接依赖可能仍然存在(比如对 gopkg.in/yaml.v3 的依赖)。
    • 评估库的维护活跃度、背后力量、社区声誉、测试与文档。
  2. 拥抱标准库: 尽可能优先使用标准库提供的功能。
  3. 关注依赖更新: 定期检查依赖库的状态,关注安全更新 (govulncheck)。
  4. 制定预案: 对核心依赖,思考是否有替代方案?当依赖出现问题时,是否有能力 fork 并自行维护?
  5. 参与和贡献: 积极参与社区,为依赖的库贡献力量,是提升生态韧性的最有效方式。

小结

go-yaml 的归档及其后续讨论(特别是 K8s 的硬分叉行为和 goccy/go-yaml 的兴起)给我们上了一堂生动的 Go 生态实践课。它揭示了这个生态系统并非只有简单的“推荐路径”,而是充满了基于现实需求的pragmatic choices(务实选择),有时甚至是“硬核”的自我保护机制。

Go 的生态也许不像某些老牌语言那样拥有高度统一、组织化支持的核心框架,它更像一个充满活力、快速迭代、有时甚至略显“野蛮”生长的雨林。这里有大树(标准库、大公司开源项目),也有藤蔓(各种小而美的库),还有适应特定环境的变种(如 K8s 的硬分叉)。

作为 Gopher,我们需要理解并适应这种真实世界的复杂性,用更审慎的态度选择依赖,用更积极的心态参与社区,共同塑造一个更健壮、但也承认多元选择的 Go 生态。

与其过度担忧,不如积极拥抱,用更专业的眼光审视依赖,用更主动的姿态参与贡献。Go 生态的未来,掌握在每一个 Gopher 手中。

那么,未来 YAML 是否还有机会进入Go标准库呢?Go团队推荐的go-yaml/yaml的归档为这件事撬开了一丝丝缝隙,可能更大的难度在于yaml规范的复杂性本身,不过现在我们也可以小小期待一下!

你对 Go 的开源生态有何看法?在项目中遇到过类似 go-yaml 的情况吗?你是如何应对的?欢迎在评论区分享你的经验和思考!


深入探讨,加入我们!

今天讨论的 Go 开源生态话题,只是冰山一角。在我的知识星球 “Go & AI 精进营” 里,我们经常就这类关乎 Go 开发者切身利益、技术选型、生态趋势等话题进行更深入、更即时的交流和碰撞。

如果你想:

  • 与我和更多资深 Gopher 一起探讨 Go 的最佳实践与挑战;
  • 第一时间获取 Go 与 AI 结合的前沿资讯和实战案例;
  • 提出你在学习和工作中遇到的具体问题并获得解答;

欢迎扫描下方二维码加入星球,和我们一起精进!

img{512x368}

参考资料


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats