Golang - Tony Bai

本文永久链接 – https://tonybai.com/2025/05/17/java-at-30

大家好，我是Tony Bai。我的极客时间《Go进阶课》专栏已经上线，欢迎大家点击链接订阅学习，我们一起在Go语言的道路上共同精进！

Go语言自开源以来，已走过十多个年头。从最初备受瞩目的“Google语言”，到如今在云原生、微服务领域独当一面，Go 凭借其简洁、高效与强大的并发能力，赢得了全球开发者的青睐，正从一个朝气蓬勃的少年”迈向更加成熟稳健的“壮年”。

然而，“成长的烦恼”也随之而来：生态如何持续繁荣？语言如何在保持核心优势与满足新兴需求之间取得平衡？如何应对一波又一波的技术浪潮冲击？

恰逢 Java 语言诞生 30 周年，The New Stack 对 Java 之父 James Gosling 进行了一次深度访谈。我刚接触 Java 时，它才发布 1.5 版本（Tiger），一晃近 20 年，Java 依然是全球最重要的语言之一。这位编程语言界的“老大哥”和它的创造者，其“长寿秘诀”无疑能为“风华正茂”的 Go 语言带来诸多启示。

Gosling 在访谈中分享了 Java 长盛不衰的关键，我提炼了几点，希望能为Go的未来之路提供一些借鉴与思考。

秘诀一：【解决真实问题，而非追逐时髦】—— Go 的初心与未来挑战

Java 的经验： James Gosling 强调：“Java 从不追求时髦，始终专注于有效解决问题，帮助工程师完成工作。” 这份对实用主义的坚守，是 Java 能够穿越多个技术周期的基石。
Go 的启示与思考： Go 语言的诞生，正是为了解决当时 C++ 开发的复杂性、Python 等脚本语言的性能瓶颈以及多核时代并发编程的困境。它以大道至简的哲学，直击痛点，迅速在云原生、分布式系统等领域找到了自己的核心价值。

如今，Go 已走过开源的第一个十年，生态日渐成熟。面对 AI 浪潮、不断演进的硬件架构以及更多元化的应用场景，Go 是否还能保持这份“解决真实问题”的初心？未来，Go 需要识别并解决哪些新的、关键的“真实问题”，以巩固和拓展自身的生态位？这是每一个 Gopher 和 Go 社区贡献者都需要思考的。

秘诀二：【尊重用户，死磕向后兼容与可靠性】—— Go 的生命线如何延续？

Java 的经验： “尊重用户”、“保持向后兼容”、“优先考虑可靠性 (必须每次都TM的能用！)”——Gosling 的这些话掷地有声，道出了 Java 赢得企业信任的关键。
Go 的启示与思考： Go 语言著名的“Go 1 兼容性承诺”为其赢得了极佳的口碑，让开发者能够放心地升级版本。然而，随着 Go Modules、泛型等重要特性的引入，社区中也出现了一些关于“必要妥协”与“更大收益”的讨论。

当 Go 生态越来越庞大，用户场景越来越复杂时，如何在不牺牲核心稳定性的前提下，引入必要的改进和演化？如何在社区对某些“破坏性但可能带来更大价值”的变革呼声与“向后兼容”的承诺之间找到最佳平衡点？这将持续考验 Go 核心团队的智慧和社区的共识。

秘诀三：【谨慎创新，不轻易破坏核心价值】—— Go 的“简洁”能否持久？

Java 的经验： 谈及 Lambda、泛型等重要特性时，Gosling 表示：“我从不想加入一个不‘对’的东西。”他坦言确定最佳实现方式的艰难（“最初的90%很容易想出来，但最后10%超级难”）。这种对语言核心价值的审慎态度，避免了 Java 过早地陷入复杂性的泥潭。
Go 的启示与思考： Go 在引入泛型时，同样经历了长达数年的社区讨论和极其审慎的设计过程，最终才在 Go 1.18 中落地。这种“慢”在某种程度上保证了新特性与 Go 整体设计哲学的融合。

未来，Go 必然会面临更多引入新特性的需求。如何在满足发展需要与保持语言核心的“简洁性”和“工程效率”之间取得平衡，避免语言的“膨胀”和“复杂化”，将是 Go 能否保持其独特魅力的关键。我们是否应该继续推崇“少即是多”？哪些领域的创新是必要的，哪些又是需要警惕的？

秘诀四：【社区是活水之源】—— Go 的生态如何更上一层楼？

Java 的经验： 即便在 Oracle 的管理下（Gosling 对 Oracle 的评价是“比预想的好，但期望本来就很低”），他也承认社区在 Java 持续发展和创新中扮演了至关重要的角色。
Go 的启示与思考： Go 拥有一个全球化、充满活力且贡献卓著的社区。从无数优秀的开源项目到各种技术峰会、meetup，社区的力量是 Go 快速成长的重要驱动力。

进入成熟期后，如何进一步赋能社区，形成更强大的合力？例如，在语言特性方面(如更完善的错误处理、更丰富的原生数据结构支持等，虽然泛型已带来一些改善），如何更好地组织和激励社区进行共建？如何让更多的企业和个人开发者参与到 Go 的核心贡献和生态治理中？这将是 Go 能否持续保持创新活力的关键。

秘诀五：【保持清醒的自我定位，警惕技术炒作】—— Go 在浪潮中的定力

Java 的经验： Gosling 对当前 AI 热潮的一些犀利点评（例如，称其为“自带一桶有毒废料的营销术语”，认为“大部分 AI 投资将化为乌有”，以及 AI 编码工具在复杂项目中“几乎总是会崩溃”）展现了一种宝贵的清醒和批判精神。他认为 AI 更多是“极其复杂的锤子和螺丝刀”，是人类使用的工具，而非取代人类的自主系统。
Go 的启示与思考： 面对一波又一波的新兴技术浪潮（从区块链到元宇宙，再到如今的生成式 AI），Go 语言需要有清晰的自我认知和战略定力。它在技术栈中的核心价值是什么？最适合解决哪些领域的问题？

Go 在并发处理、网络编程、系统构建方面的优势，使其在云原生、微服务、分布式系统以及 AI 应用的后端基础设施等领域大放异彩。未来，Go 如何在这些领域继续深耕，同时审慎地探索与新兴技术的结合点，而不是被短期热点裹挟，盲目扩张，这将考验 Go 社区的集体智慧。

小结：知易行难，未来可期

James Gosling 的访谈，不仅仅是对 Java 30 年的回顾，更像是一堂浓缩的技术发展史和语言设计哲学课。虽然很多“名言警句”（比如他对某些公司文化的吐槽，或者对过时工具的调侃）非常抓人眼球，但其背后对技术本质的坚守、对用户价值的尊重、以及对行业趋势的冷静洞察，或许才是 Java 能够穿越周期、屹立 30 年的深层原因。

Go 语言，这位“刚刚十多岁的少年”，正处在发展的黄金时期，也面临着成长的关键抉择。借鉴 Java 这位“老大哥”的宝贵经验，或许能帮助 Go 走得更稳、更远。

想更全面了解 James Gosling 的观点和那些有趣的编程往事吗？推荐阅读原文：
Java at 30: The Genius Behind the Code That Changed Tech

聊一聊，聚焦 Go 的未来：

你认为当前 Go 语言发展面临的最大挑战是什么（技术层面或生态层面）？
借鉴 Java 的经验，你觉得 Go 社区或官方在哪些方面可以做得更好，以确保其长期健康发展？
对于 Go 语言的核心价值（如简洁、并发、工程效率），你认为在未来演进中最需要坚守的是什么？

欢迎大家围绕 Go 的未来发展，在评论区分享你的深度思考！如果你觉得这篇文章对你有所启发，也请转发给你身边的 Gopher 朋友们，让我们一起为 Go 的未来出谋划策。

想与我进行更深入的 Go 语言与 AI 技术交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

img{512x368}

我们星球见！

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

本文永久链接 – https://tonybai.com/2025/05/16/how-rune-came

大家好，我是Tony Bai。

作为 Gopher，我们每天都在和 rune 打交道。在 Go 语言中，它通常被解释为“一个 Unicode 码点”，官方文档也说引入这个术语是为了“简洁”。但你是否曾好奇，这个略带神秘色彩的词汇，究竟源自何方？仅仅是为了简洁吗？

最近，Connor Taffe的一篇精彩博文以及 Go语言之父 Rob Pike 的亲自确认，为我们揭开了一段跨越三十余年，从 Plan 9 操作系统到 UTF-8 编码诞生，再到 Go 语言的历史传奇。今天，就让我们一起，深入 rune 背后的故事。

一句“简洁”，一段 Plan 9 往事

Connor文章中引用的Adam Pritchard的关于限制字符串长度的文章中提到：“请注意，在 Go 中，Unicode 码点通常被称为‘rune’。（Go 似乎是为了简洁而引入了这个术语。）” 而 Go 官方博客《Strings, bytes, runes, and characters in Go》也说：“‘Code point’有点拗口，所以 Go 引入了一个更短的术语：rune。”

Rob Pike 在 Bluesky 上的发言截图

然而，真相远不止于此。Rob Pike 最近在 Bluesky 上澄清(如上图)，rune 这个词实际上是 Ken Thompson 在一次为 Plan 9 寻找一个不同于 char（用于字节）的类型名称的头脑风暴中“得意地”提出的，Rob Pike 当即表示赞同。更关键的是，Rob Pike 随后确认，这个命名发生在 Plan 9 为 UTF 和 ISO 10646 寻找类型名称的时期，具体是1991 年 12 月 8 日的晚上！远早于 Unicode 和 UTF-8 的广泛应用，也比 Go 语言的诞生早了数十年。

是的，你没看错，rune 的故事，始于 Plan 9，那个由贝尔实验室传奇人物们（包括 Rob Pike, Ken Thompson 等）创造的操作系统。Go 语言深受 Plan 9 的影响，从链接器架构、并发原语 channel、标识符大小写的可见性规则，到对简洁性的极致追求，都带着浓厚的 Plan 9 印记。rune 便是这血脉传承中的一环。

餐巾纸上的革命：UTF-8 的诞生传奇

要理解 rune 在 Plan 9 中的意义，就不得不提 UTF-8 的诞生。Connor 的文章中引用了一封 Rob Pike 在 2003 年的邮件，详细披露了这段鲜为人知的历史，纠正了“IBM 设计 UTF-8，Plan 9 实现它”的说法。

故事发生在 1992 年 9 月左右的一个晚上，新泽西一家小餐馆的餐巾纸上：

缘起： Plan 9 当时使用 ISO 10646 最初的 UTF（一种16位字符编码）来支持宽字符，但团队对它非常不满。Rob Pike 形容道：“UTF 太糟糕了。它有模192的算术，而且在没有除法硬件的老 SPARC 机器上几乎不可能高效实现。像【/*】这样的字符串可能出现在西里尔字符中间，导致你的俄文文本变成一个 C 语言注释。还有更多问题。它作为一种编码根本不实用。”
契机： 一天下午，X/Open 委员会的一些人（据 Rob Pike 回忆可能来自 IBM 奥斯汀）打来电话，希望 Ken 和 Rob 审查他们的 FSS-UTF (File System Safe UTF) 设计。Ken 和 Rob 意识到这是一个用他们的经验设计一个真正优秀的标准，并让 X/Open 将其推广出去的机会。
餐巾纸上的灵感： 他们接受了挑战，条件是必须快速完成。于是，在那个决定性的晚餐上，Ken Thompson 在餐巾纸上构想出了 UTF-8 的位打包方案。
闪电般的实现： 晚餐后回到实验室，他们便向 X/Open 解释了新方案，并承诺在周一前（据信是 X/Open 的重要投票日）拿出一个完整的运行系统。当晚，Ken 写了打包和解包代码，Rob Pike 则开始修改 C 库和图形库。到周五的某个时候，Plan 9 已经完全运行在后来被称为 UTF-8 的编码上了。

Rob Pike 在邮件中强调，他们之所以要“另起炉灶”，是因为 FSS-UTF 缺少他们认为至关重要的特性之一：支持定位到文件或流的中间，并读取有效字符，或处理损坏的字符。 Ken Thompson 设计的 UTF-8 完美地解决了这个问题。

对比 Ken Thompson 当时提出的 UTF-8 方案(如下图)和 FSS-UTF，我们可以看到 UTF-8 的精妙之处：后续字节以 10 开头，与首字节的 110、1110 等模式区分开来，确保了自同步性和对 ASCII 的兼容性。

Rune 的首次亮相与演变

那么，Rune 这个词是什么时候正式与这种新的字符表示方式联系起来的呢？Rob Pike 在其关于 Plan 9 UTF-8 实现的论文《Hello World》中写道：

“在语义层面上，ANSI C 允许（但并未限制）宽字符的概念，并且允许此类字符串和字符常量。我们选择 unsigned short 作为宽字符类型。在库中，Rune 一词由 typedef 定义为等同于 unsigned short，并用于表示一个Unicode 字符。”

这似乎是 Rune 作为一种特定类型名称，用于指代 Unicode 字符（码点）的最早文献记录。最初在 Plan 9 C 中，Rune 是一个 16 位无符号短整型，足以表示当时的 Unicode 基本多文种平面（BMP）。

而到了 Go 语言，rune 被定义为 int32 的别名。这是因为自 1992 年以来，Unicode 已经扩展，需要更大的空间来表示所有码点（UCS-4 定义了 31 位码空间）。Go 语言标准库中的 unicode/utf8 包也定义了 UTFMax = 4，表明一个 rune 最多可以用 4 个字节的 UTF-8 编码表示。有趣的是，在 Russ Cox 移植的 plan9 port 中，Rune 类型在 2009 年末也被修改为了 unsigned int，同样是为了支持更广的码点范围。

Ken Thompson 在最初的邮件中提到：“4、5 和 6 字节序列只是出于政治原因才存在的。我更愿意删除它们。” 这也印证了早期设计者对编码效率和实用性的极致追求。

Rune 的足迹：从 Plan 9 到更广阔的世界

Rune 这个术语，并没有止步于 Plan 9。通过 Paul Borman 的贡献，Plan 9 的 rune 功能被整合进了 4.4 BSD。从此，rune 开始在更广阔的 Unix 世界留下足迹：

FreeBSD 继承了 4.4 BSD 的 rune 函数，尽管后来推荐使用 ISO C99 的宽字符工具。
Apple 的 Darwin 内核，作为 BSD 的衍生，也包含了 rune_t 类型。
C 标准库实现如 newlib 也包含了源自 BSD 4.4 的 rune 功能。
Android 通过 plan9port 移植了 Plan 9 的 libutf，其中自然也包含了 rune。
甚至，微软的 .NET 在引入 System.Text.Rune 类型时，其灵感也明确来自 Go 语言，这在其 GitHub issue 中由 Miguel de Icaza 提及。

可见，rune 这个由 Ken Thompson 灵光一闪提出的词汇，承载着一段从贝尔实验室 Plan 9 开始，经由 BSD 社区，最终深刻影响了包括 Go 在内的现代编程语言和操作系统的字符处理历史。

小结：rune 不只是简洁

通过Rob Pike的亲自确认，我们应该知道，当我们今天再看到 Go 语言中的 rune 时，它不仅仅是为了“简洁”而对“Unicode code point”的替换。它是一个承载着厚重历史的符号，是 Go 语言设计者们深厚技术底蕴和创新精神的体现，是 Plan 9 简洁哲学与 UTF-8 实用主义的结晶。

理解 rune 的来龙去脉，有助于我们更深刻地体会 Go 语言在文本处理、字符串操作以及 Unicode 支持方面的设计考量，也让我们对这门语言背后的巨匠们多一份敬意。下一次，当你在 Go 代码中写下 rune 时，或许会想起那个在新泽西餐馆餐巾纸上诞生的传奇，以及那段跨越三十余年的 Plan 9 往事。