标签 RussCox 下的文章

哲学家与工程师:为何 Rust 和 Go 的“官方之声”如此不同?

本文永久链接 – https://tonybai.com/2025/08/21/go-rust-official-voices

大家好,我是Tony Bai。

最近,在阅读 Rust 核心团队负责人 Niko Matsakis 庆祝十周年的系列博文时,我注意到了一个有趣的现象。我下意识地将他的文字,与我长期关注的 Go语言之父Rob Pike以及Go 团队前技术负责人 Russ Cox 的文章放在一起对比。

这时我发现,两者窗外的风景截然不同。

一边,Niko Matsakis 这样写道:

“Graydon(Rust创始人)为我们设定了正确的‘北极星’……‘是的,我们可以拥有好东西’,我常这么想。这句话也捕捉到了 Rust 的另一种特质,那就是试图挑战关于‘权衡’的传统智慧。”

另一边,Russ Cox 在一篇关于 Go 模块依赖的重要文章中,开篇即是:

“本文定义了 Go 模块,这是对 go get 命令支持的版本化依赖的提议。这篇文章是七篇文章中的第一篇,描述了一个关于版本化 Go 的全面提案。”

可以看到,一种声音像一位哲学家,在讨论愿景和原则;另一种,则像一位总工程师,直接给出工程计划。

这并非偶然的文笔差异。

一门编程语言核心团队的写作风格,不只是表面的文字选择,而是其设计哲学、治理模式和社区文化的直接反映。 它在很大程度上预示了这门语言的演进方向,以及它最终会吸引哪一类开发者。

今天,我想和你一起分析这两种迥异的“官方之声”,并尝试回答一个核心问题:

在 Rust 的哲学思辨与 Go 的工程决断之间,究竟隐藏着怎样的语言灵魂与未来?

Rust 的“探索式叙事”——在复杂世界中寻求赋能

如果你长期阅读 Rust 官方博客或 Niko Matsakis 的个人博客,会发现一种独特的叙事模式:愿景驱动,讨论权衡,社区对话。

Niko 的“Rust 2025”系列,开篇并非罗列要实现的功能,而是先定义 Rust 的“核心使命”——赋能基础软件。他花了不少篇幅来构建一个叙事框架,用“北极星”来比喻指引方向的技术与文化原则,用“大力水手菠菜”来形容类型系统的作用,用“平滑的迭代式深化”来描述理想的用户体验。

这种风格的背后,是对一个根本事实的承认:系统编程本身是复杂的。

Rust 的设计哲学,不是回避这种复杂性,而是正视它,并提供一套强大的工具去驾驭它。这套工具,就是其所有权系统、生命周期和 Trait 系统。

这些工具无疑是复杂的,也带来了陡峭的学习曲线。但 Rust 官方文章的字里行间,总是在传达一个核心信念:这种复杂性,是为了换取一种前所未有的“赋能 (Empowerment)”。

当你掌握了这些工具,你便能在编译器的帮助下,编写出兼具高性能、内存安全和高度抽象的代码。这是一种“先难后易”的设计。Rust 的文章,就像一位向导,它不否认前路复杂,但会耐心解释工具的用法,并清晰地展示目标达成后所能获得的能力,让你相信这种投入是值得的。

这种“探索感”也体现在 Rust 的社区文化和治理模式上。

Niko 在文章中反复使用 “我们 (we)” 这个词,而这个“我们”,指代的通常是整个 Rust 社区和所有贡献者。他乐于讲述 ACM 获奖名单难产的故事,以此来证明 Rust 的成功是“集体所有”的。

这种对话式的风格,与其开放的 RFC (Request for Comments) 流程是一致的。任何重大的语言变更,都必须经过漫长、公开的社区讨论。Rust 的进化,是一个由全球开发者共同参与、自下而上推动的过程。

所以,当你阅读 Rust 的“官方之声”时,你其实是在了解一个公开的设计讨论。它邀请你一起思考“什么是更好的软件”,并相信通过集体的智慧,能够不断接近理想的答案,哪怕过程充满思辨与权衡。

Go 的“工程化叙事”——在现实世界中追求简洁

现在,让我们切换到 Go 的世界。

如果你阅读 Russ Cox 或 Rob Pike 的文章,会立刻感受到一种截然不同的气息:问题驱动,逻辑清晰,方案明确。

Go 的文章,几乎总是以一个具体的、待解决的工程问题开篇。无论是包管理的混乱,还是泛型的缺失,他们会用严谨的逻辑,一步步地分析问题背景、评估现有方案,最终给出一个经过深思熟虑的官方提案。

这里没有宏大的比喻,取而代之的是清晰的数据、代码示例和对各种边界情况的分析。他们追求的不是思想的深邃,而是方案的“显而易见 (obvious)”

这种风格背后,是对另一个根本事实的坚守:大规模软件工程的核心挑战,是控制复杂性。

Go 的设计哲学,可以概括为“规定性的简单性 (prescriptive simplicity)”。它相信,通过提供一个更小的工具集,并制定严格的工程规范(如 gofmt),可以显著降低团队协作的认知成本,从而提升整体生产力。

Go 团队清楚,每一个新加入语言的特性,都是一种“复杂性预算”的支出。因此,他们对此极为审慎。泛型这个功能,Go 社区讨论了近十年,核心团队才最终拿出一个他们认为足够简单、不会破坏 Go 核心价值的方案。

在这种哲学下,Go 的文章读起来就像一份工程白皮书。它不展示所有可能的路径,而是直接告诉你那条经过专家团队验证过,被认为最平坦、最宽阔的道路。它传递的核心信念是:“相信我们,这条路最简单直接,最能规模化。”

这种“决断感”也体现在 Go 的治理模式上。

Go 的演进,更多是由一小群核心专家(很多来自 Google)主导的“自上而下”模式。虽然他们也会通过提案流程征求社区反馈,但最终的决策权高度集中。文章中,“我们 (we)”这个词,更多时候指代的是 Go 核心团队。

这种模式保证了 Go 的稳定性和向后兼容性,但也意味着语言的演进会更加保守。Go 的进化,更像是一系列精准解决现实问题的“外科手术”,而非一场开放式的探索。

所以,当你阅读 Go 的“官方之声”时,你其实是在看一份来自顶级工程团队的技术报告。它不侧重于邀请你参与设计权衡,而是直接为你提供一个经过验证的、旨在解决你当前问题的最佳实践。

文字的岔路口,语言的未来

这两种截然不同的叙事风格,如同两条岔路,清晰地预示了 Rust 和 Go 在未来演进道路上的不同选择。

Rust 的未来,将是一场对语言能力边界的持续探索。

它会继续在“可扩展编译器”、“语言互操作”、“函数Traits”等领域,尝试为开发者提供更强大的“赋能”工具。它的进化过程将继续是思辨性的、社区驱动的,充满思想碰撞。这也可能意味着,它的学习曲线在短期内不会变得平缓,而重大的新特性,依然需要较长的讨论和共识周期。

Go 的未来,则是一场稳健的工程建设。

它将继续保持克制和实用主义。下一个重大变更,几乎可以肯定是为了解决大规模工程中出现的下一个具体痛点(比如,可感知NUMA的GC、对SIMD指令的内置支持等)。Go 会极力捍卫其“简单”的核心价值,避免任何可能导致语言心智模型复杂化的改动。它的进化将是可预测的、问题驱动的。

在这里,我想提出一个或许能概括两者差异的观点:

Rust 试图通过提供复杂的工具,让你成为一个思考更周全、能力更强的程序员;而 Go 则试图通过提供简单的工具,让你立即成为一个在团队中高效协作的程序员。

一个是授你以渔,但渔具复杂;一个是直接给你一条标准化的、足够好用的鱼竿。

小结:开发者如何选择?——聆听与你共鸣的声音

到这里,我们已经清晰地看到,Rust 和 Go 的“官方之声”背后,是两套截然不同的世界观。

  • Rust 的世界观是赋能与驾驭: 它相信通过赋予开发者强大的工具,可以驾驭固有的复杂性,构建出理论上最优的软件。
  • Go 的世界观是约束与纪律: 它相信通过设定清晰的约束,可以消除不必要的复杂性,构建出工程上最稳健、最易于维护的软件。

那么,作为开发者,我们该如何选择?

我的建议是,超越那些性能跑分和“Hello World”的语法对比,去读一读他们核心团队的文章吧

问问你自己:

  • 你是更倾向于一场开放式的、关于“可能性”的哲学讨论,还是更需要一份逻辑严密、直指问题核心的工程方案?
  • 你是在寻找一个与你一同探索复杂问题的“伙伴”,还是一个为你提供清晰建造指南的“总工程师”?

这个问题的答案,可能比任何技术指标都更能决定你的项目能否成功、你的团队是否快乐。

因为最终,我们选择一门编程语言,远不止是选择一个编译器和一套库。我们是在选择一个与之共鸣的社区,一套解决问题的世界观,一种塑造我们思维方式的技术文化。

而这一切,早已写在了他们的字里行行间。

你,听到了哪种声音的回响?


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

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

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

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

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


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

Go 错误处理语法之争尘埃落定?Go 团队为何十五年探索后仍选择“不”

本文永久链接 – https://tonybai.com/2025/06/04/error-syntax

大家好,我是Tony Bai。

长久以来,Go 语言中 if err != nil 的错误处理模式因其普遍性和由此带来的代码冗余,一直是社区反馈中最持久、最突出的痛点之一。尽管 Go 团队及社区投入了大量精力,历经近十五年的探索,提出了包括 check/handle、try 内建函数以及借鉴 Rust 的 ? 操作符在内的多种方案,但始终未能就新的错误处理语法达成广泛共识。近日,Go 官方团队通过一篇博文正式阐述了其最新立场在可预见的未来,将停止寻求通过改变语法来简化错误处理,并将关闭所有相关的提案。 这一决策无疑在 Go 社区引发了广泛关注和深入思考。

漫漫探索路:从 check/handle 到 ? 操作符

Go 语言的错误处理冗余问题,尤其在涉及大量 API 调用且错误处理逻辑相对简单的场景下尤为突出。一个典型的例子如下:

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return err // 样板代码
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return err // 样板代码
    }
    fmt.Println("result:", x + y)
    return nil
}

在这个函数中,近一半的代码行用于错误检查和返回,这无疑增加了代码的视觉噪音,降低了核心逻辑的清晰度。因此,多年来,改进错误处理的呼声在 Go 开发者年度调查中一直居高不下。

Go 团队对此高度重视,并进行了一系列尝试:

check/handle 机制 (2018年)

由 Russ Cox 正式提出,基于 Marcel van Lohuizen 的草案设计。该机制引入了 check 用于检查错误并提前返回,handle 用于定义错误处理逻辑。

// 设想的 check/handle 用法
func printSum(a, b string) error {
    handle err { return err } // 定义错误处理
    x := check strconv.Atoi(a) // 检查错误
    y := check strconv.Atoi(b) // 检查错误
    fmt.Println("result:", x + y)
    return nil
}

然而,该方案因其复杂性未被广泛接受。

try 内建函数 (2019年)

作为 check/handle 的简化版,try 函数会在遇到错误时从其所在的封闭函数返回。

// 设想的 try 用法
func printSum(a, b string) error {
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x + y)
    return nil
}

尽管 Go 团队投入巨大,但 try 因其隐式的控制流改变(可能从深层嵌套表达式中返回)而遭到许多开发者的反对,最终也被放弃。Go 团队反思,或许引入新关键字并限制 try 的使用范围会是更好的路径。

借鉴 Rust 的 ? 操作符 (2024年)

由 Ian Lance Taylor 提出,希望通过借鉴其他语言中已验证的机制来取得突破。

// 设想的 ? 操作符用法
func printSum(a, b string) error {
    x := strconv.Atoi(a) ?
    y := strconv.Atoi(b) ?
    fmt.Println("result:", x + y)
    return nil
}

此方案虽然在小范围用户研究中表现出一定的直观性,但在社区讨论中依然未能形成足够支持,并引发了大量关于细节调整的建议。

除了官方提案,社区也贡献了数以百计的错误处理改进方案,但无一例外都未能获得压倒性的支持。

官方立场:为何按下暂停键?

面对多年探索未果的局面,Go 团队基于以下几点理由,做出了暂停错误处理语法层面改进的决定。

缺乏社区共识

这是最核心的原因。根据 Go 的提案流程,一项提案需要得到社区的普遍共识才能被接受。然而,在错误处理语法这个问题上,无论是官方还是社区的提案,都未能凝聚起足够的共识。甚至 Go 团队内部也未能就最佳方案达成一致。

维护现状的合理性

  • 时机问题: Go 已经发展了十五年,现有的错误处理方式虽然冗余,但功能完善且被广泛理解和使用。早期引入语法糖可能更容易被接受,但现在改变的门槛更高。
  • 避免制造新的“不快乐”: 即使找到了“完美”方案,强制推广新语法也可能让习惯了现有方式的开发者感到不适,重蹈类似泛型引入初期的一些争议。但与泛型不同,错误处理语法几乎会影响所有开发者。
  • Go 的设计哲学: Go 倾向于“只提供一种(或尽可能少)的方式来做同一件事”。引入新的错误处理语法会打破这一原则。有趣的是,:= 短变量声明中的变量重声明规则,最初也是为了解决连续错误检查中 err 变量命名问题而引入的,如果早期有更好的错误处理语法,这个规则或许就不需要了。

关注错误处理的本质,而非仅仅语法

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return fmt.Errorf("invalid integer: %q", a) // 附加信息
    }
    // ...
    return nil
}

在这种情况下,if err != nil 的样板代码占比相对减小。

  • 标准库的增强: 新的库函数(如 cmp.Or)或未来的库特性,可以在不改变语法的情况下帮助减少错误处理的样板代码。
func printSum(a, b string) error {
    x, err1 := strconv.Atoi(a)
    y, err2 := strconv.Atoi(b)
    if err := cmp.Or(err1, err2); err != nil { // 使用 cmp.Or
        return err
    }
    fmt.Println("result:", x+y)
    return nil
}

工具的辅助作用

  • 编写时: 现代 IDE(包括基于 LLM 的工具)已经能够很好地辅助生成重复的错误检查代码。
  • 阅读时: IDE 或可提供隐藏/折叠错误处理代码块的功能,减少视觉干扰。
  • 调试时: 显式的 if 语句更便于设置断点和添加调试输出,而高度集成的语法糖可能会使调试变得复杂。

语言演进的成本与优先级

  • 任何语言的改动都伴随着巨大的成本:设计、实现、文档更新、工具调整以及社区的适应。Go 团队规模有限,需要优先处理其他重要事项。
  • 开发者习惯的演变: 许多有经验的 Go 开发者表示,随着对 Go 错误处理哲学的深入理解和实践,最初感到的冗余问题会逐渐减轻。

对开发者的影响与未来展望

Go 团队的这一决定,意味着在可预见的未来,if err != nil 仍将是 Go 语言错误处理的标准范式。开发者需要:

  • 接受现状并深入理解其哲学: Rob Pike 的名言“Errors are values”依然是理解 Go 错误处理的核心。错误是程序正常流程的一部分,显式处理它们有助于编写健壮的软件。
  • 利用现有工具和库:
    • 善用 IDE 的代码生成和辅助功能。
    • 探索和使用标准库或第三方库提供的错误处理辅助工具(如 errors.Is, errors.As, fmt.Errorf 的 %w 以及可能的新库特性)。
  • 关注代码质量而非单纯追求简洁: 在需要详细错误上下文的地方,不要吝啬代码。清晰、可追溯的错误比极度简化的语法糖更有价值。
  • 代码可读性依然重要: 尽管语法层面不再追求极致简洁,但在错误处理逻辑本身,依然要力求清晰、易懂。

Go 团队也指出,他们并未完全关闭对错误处理改进的大门,只是将焦点从“语法层面”移开。未来可能会更深入地研究错误处理的本质问题,例如如何更好地构造和传递包含丰富上下文的错误信息,以及通过库而非语法来提供更好的支持。

小结

Go 语言在错误处理语法上的探索历程,充分体现了其在语言设计上的审慎与对社区反馈的重视。尽管长达十五年的努力未能催生出被广泛接受的新语法,但这并不代表失败,而是对 Go 核心设计原则的坚守和对现实复杂性的认知。

对开发者而言,这意味着需要继续在现有的、经过验证的错误处理模式下精进技艺,同时期待 Go 语言在库和工具层面带来更多辅助,以更优雅、更高效地构建可靠的应用程序。

这场关于错误处理的“语法之争”虽然暂时告一段落,但其引发的关于简洁、清晰、实用与语言稳定性的思考,将对 Go 的长远发展产生深远影响。


对于 Go 官方在错误处理语法上的最新立场,您有什么看法?您认为现有的 if err != nil 模式在您的日常开发中体验如何?欢迎在评论区分享您的观点和实践经验!

想要更深入地掌握 Go 语言的错误处理哲学、高级技巧以及更多进阶主题吗?欢迎订阅我的《Go语言进阶课》专栏,与我们一同探索 Go 的魅力,提升您的 Go 开发技能!


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 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