标签 Gopher 下的文章

为什么 Go 在悄悄地做 Rust 做不到的事:保持简单

本文永久链接 – https://tonybai.com/2025/11/21/why-go-is-quietly-doing-what-rust-couldnt-staying-simple

大家好,我是Tony Bai。

近日,一篇题为《为什么 Zig 在悄悄地做 Rust 做不到的事:保持简单》的文章在开发者社区引发了热议。文章以其辛辣、富有煽动性的文风,将 Zig 描绘成 Rust 复杂性的“解毒剂”,是“一个终于接受了心理治疗的 C 项目”,并引发了关于“简单性”与“安全性”的深刻辩论。

这不禁让我们——作为 Go 社区的观察者——产生了一个有趣的想法:如果我们将文中的主角 Zig,完全替换为 Go,这篇文章的论点是否依然成立?

Go 语言,在其诞生之初,同样被视为对 C++ 等语言复杂性的“反叛”。它与 Zig 在追求编译速度、二进制简洁性以及“显式优于隐式”的哲学上,有着惊人的相似之处。

于是,我们进行了一次大胆的“思想实验”:在保留原文犀利风格和核心论证结构的前提下,将所有关于 Zig 的部分都替换为 Go,并将代码示例“翻译”为地道的 Go 代码。

这并非意在挑起 Go 与 Rust 之间的“战争”,而是希望通过这样一次“角色扮演”,从一个全新的、极具张力的视角,来重新审视 Go 语言的设计哲学,以及它在现代编程语言光谱中所占据的那个独特、宝贵且时常被误解的位置。

以下,便是这次思想实验的成果。各位小伙伴儿品一品,这样替换后,是不是不仅完美地道出了 Go 在“简单”与“显式”上的坚持,更说出了许多 Gopher 心里想说,却又不好意思直接对 Rust 爱好者说出口的‘真心话’?


Rust 对安全性大声疾呼。Go 只是把它构建了进去——没有那些仪式感、没有那些说教、也没有那 15 分钟的编译时间。

引子

我第一次写 Go 代码的时候,忍不住笑出声来。不是因为它好笑——而是因为我不敢相信,在现代编程世界里,还存在着如此……安静的东西。

在与 Rust “搏斗”多年之后——那门承诺将我们从 C 的苦海中拯救出来,却不知怎的变成了一场性格测试的语言——Go 感觉就像是 Rust 霓虹闪烁的都市中心里,一间温暖、极简的小木屋。

而这,正是关键所在。

Go 并非试图成为未来。它只是想保持理智。


Rust 承诺了天堂,却给了我们一堆文书工作

还记得那股炒作的热潮吗?Rust 是“C 语言杀手”,是内存安全的“弥赛亚”,是系统编程的“救世主”。

平心而论,Rust 确实……算是兑现了。你可以写出快如闪电的安全代码——在你向借用检查器献祭了三只山羊和整个周末的心智健全之后

你看着这样的代码:

// Rust
fn main() {
    let mut data = vec![1, 2, 3];
    let ref1 = &data;
    data.push(4); // 借用检查器:“凡人,你不能这么做。”
    println!("{:?}", ref1);
}

你会想,为什么?为什么我的编译器听起来像我的前任在解释情感边界?

Rust 像一个严厉的治疗师一样教你所有权。而 Go 呢,只是耸耸肩说:“你搞坏了,你修好它。”

这就是哲学的分水岭。Rust 假设你不可信。Go 假设你是个成年人。

Rust 的才华毋庸置疑——安全、并发、无畏的重构。但它也……让人筋疲力尽。那些仪式感。那些工具链。那种将过度工程伪装成纯粹性的文化。

而 Go 呢,穿着连帽衫,拿着半个三明治出现,说:“嘿,想不想直接把该死的二进制文件构建出来?”


无聊之美

这是大多数人忽略的一点:简单不是一个特性。它是一种反叛。

Go 看起来很无聊。感觉也很无聊。读起来就像一个终于接受了心理治疗的 C 项目。

// Go
package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

就是这样。没有宏。没有 build.rs。没有 Cargo 尖叫着说哪个 crate 过期了。

仅仅。一个。编译器。

其底层呢?一个能让你团队喜极而泣的设计:

  • 没有隐藏的控制流。
  • 没有未定义行为。
  • ** 没有运行时的“惊吓” (No runtime surprises)**。(即,没有像 JIT 或复杂后台进程那样,会产生不可预测行为的“魔法”运行时)
  • 一个像钟表一样精确工作的确定性构建系统。

你可以去读 Go 编译器的源码,并且真的能读懂它。你去试试读 Rust 的编译器源码,那你需要咖啡因、心理治疗和一个祈祷小组。

Go 不性感。它很实用。它是那种你会忘记你正在使用的语言——而这,是最高的赞美。


Rust 扩展了代码库,Go 扩展了人类

说实话吧——Rust 最大的优点也是它最大的诅咒:它迫使你思考。不停地思考。

每一行代码都是一场关于生命周期、可变性和宇宙正义的哲学辩论。

Go 呢?Go 就像是说:“嘿,这是内存。别把自己捅了就行。” (笔者注:Go是GC语言,这句直接替换zig后的表达可能不是很契合)

这很重要。尤其是在团队中。

Rust 感觉像学术界——人们在 Slack 上辩论着 monad,而功能的截止日期却在悄悄溜走。Go 感觉像那个穿着脏兮兮运动鞋、代码却能跑起来的初创公司工程师。

在 Swiggy 这样的规模下,Go 取代了 Java 后端,因为它扩展了开发团队。Go 也许正在悄悄地为系统编程做同样的事情——不是因为它“更好”,而是因为它更人性化。 (笔者注:由于有特定背景局限,这里将zig替换为Go后可能也不是很契合了)

你不需要一块精神白板来在脑中记住 12 条借用规则。你只需要……写。


讽刺的转折:Go 才是 Rust 假装要成为的样子

Rust 将自己营销为“安全的系统编程”。但它实际上是——一个系统框架

Cargo、crates、宏、过程魔法——这是一个生态系统,而不是一门语言。华丽,但沉重。

Go 把所有这些都剥离了。

没有依赖爆炸。没有语言版本混乱。没有每夜构建的轮盘赌。

最关键的是——Go 的构建系统是如此集成,如此具有确定性,以至于整个 CI/CD 的设置都感觉更清爽了。

Rust 像一座现代大教堂一样构建。Go 像一条工具腰带一样构建。

“Go 不试图保护你。它试图赋予你力量。”

这就是那场安静的反叛。Go 相信你知道自己在做什么——它只给你足够的绳子让你把事情绑在一起,而不是让你上吊。

而讽刺的是什么?Go 中那些“不安全”的部分,在实践中往往最终更安全,因为你能看到一切。没有魔法。没有语法糖。只有原始的意图。


当炒作退去,简单性胜出

每个技术周期都以同样的方式结束。

炒作机器火力全开。Medium 上的文章成倍增加。Meme 如潮水般涌来。然后有一天——凌晨两点,生产环境着火了,你只想知道为什么该死的二进制文件崩溃了。

Rust 给了你安全。但 Go 给了你清晰。

// Go
package main

import (
    "fmt"
    "os"
)

func main() {
    file, err := os.Create("output.txt")
    if err != nil {
        // 你能清晰地看到错误处理
        panic(err)
    }
    defer file.Close()

    _, err = file.WriteString("Explicit is better than implicit.")
    if err != nil {
        panic(err)
    }
}

你简直可以追踪到每一个字节。没有隐藏的分配器。没有神秘之处。

这正是老派 C 开发者所怀念的那种控制感——但现代开发者却忘记了自己也需要这种感觉。

这场安静革命的教训

  • 简单是一种权力。你的语言越可预测,你付出的认知税就越少。
  • 安全不是舒适。Rust 让你感到安全,但筋疲力尽。Go 让你感到暴露,但一切尽在掌握。
  • 你不需要另一个抽象。你需要更少的抽象。
  • 有时,无聊会赢。因为无聊的东西能扩展、能调试、能交付。

最后的思考

Rust 将继续演进。它配得上它的王座。但在某个地方,有一支小团队正在用 Go 构建——没有炒作,没有技术大会演讲,没有花哨的市场营销。

只是在悄悄地编写着那些永不崩溃、编译只需几秒、在生产环境中如幽灵般运行的干净的二进制文件。

这就是没人预见到的转折。Go 并非在与 Rust 的未来竞争。它在复活编程的过去——我们早已遗忘的那些美好部分。

而且,也许,仅仅是也许,这就是它最终获胜的方式。

资料链接:https://freedium-mirror.cfd/@daxx5/why-zig-is-quietly-doing-what-rust-couldnt-staying-simple-a47f86b3a58a


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


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

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

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

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

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


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

Go 泛型再进化:移除类型参数的循环引用限制

本文永久链接 – https://tonybai.com/2025/11/19/proposal-remove-cycle-restriction-for-type-parameters

大家好,我是Tony Bai。

自 Go 1.18 引入泛型以来,Gopher 们一直在探索其能力的边界。然而,在这片新大陆上,一直存在着一个由语言规范施加的限制,它禁止了一种强大而富有表达力的泛型模式的实现。

这个限制就是:“在一个泛型类型 T 的类型参数列表中,其约束不能直接或间接地引用 T 自身。

近日,由 Go 核心团队的 Robert Griesemer 亲自发起的一个关联提案(NO.75883),旨在移除这个约束。在经过一系列的编译器修复和深度讨论后,最终被标记为 likely accept。这意味着,Go 语言规范中关于泛型“类型参数循环引用”的这条限制,即将在未来的版本中(最早Go 1.26)被正式移除

这次微小的语法调整,将为 Go 社区解锁一种被称为“奇异递归模板模式” (Curiously Recurring Template Pattern, CRTP) 的强大能力,并对我们如何设计类型安全的泛型 API 产生深远影响。

在这篇文章中,我们将深入探讨这一重要变化,剖析其背后的技术原理、核心应用场景等。

被束缚的表达力——这条限制是什么?

让我们从一个 Griesemer 提出的、看似合理的代码开始,它在当前版本(比如Go 1.25.4)的 Go 中是非法的:

// 目标:定义一个“可比较”的元素接口
// E 应该是一个实现了 Element[E] 接口的类型
type Element[E Element[E]] interface {
    Less(other E) bool
}

// 编译器报错:invalid recursive type: Element refers to itself
// (无效的递归类型)

这段代码的意图非常清晰:我们想定义一个 Element 接口,它有一个 Less 方法,该方法接收的参数 other,其类型 E 必须和实现这个接口的类型是同一个类型。这是一种“自引用”或“递归”的类型约束。

例如,如果我们有一个 Int 类型:

type Int int

// 我们希望 Less 的参数是 Int,而不是其他实现了 Element 接口的类型
func (i Int) Less(other Int) bool {
    return i < other
}

Element[E Element[E]] 这种约束,正是为了在编译期强制执行这种“同类型比较”的保证。

然而,由于 Go 1.18 规范中的明确限制,这种优雅的、类型安全的表达方式,在过去几年中一直是一条死路。

为何需要它?—— CRTP 模式的威力

社区的讨论为我们揭示了这种“循环类型约束”的几个核心应用场景。它们都与 C++ 中的 CRTP(Curiously Recurring Template Pattern) 模式异曲同工。

Robert Griesemer 在提案中给出了一个经典的例子:如何用泛型来模拟一个数学上的“环”(Ring)。

// 未来将合法的代码
type Ring[T Ring[T]] interface {
    Zero() T
    One() T
    Add(y T) T
    Mul(y T) T
}

Ring[T Ring[T]] 这个约束,确保了 Add 和 Mul 等方法的参数和返回值,永远是实现该接口的具体类型 T,而不是某个其他也实现了 Ring 接口的无关类型。它在编译期就锁定了操作的类型闭环

Prometheus 的开发者 Bryan Boreham 在 GopherCon 2023 的演讲中,也遇到了同样的问题。在实现一个通用的 K-路归并树时,他希望定义一个通用的 Value 接口,让放入树的元素自带类型安全的 Less 方法,而不是依赖外部传入的闭包。这不仅能让 API 更简洁,更重要的是,直接的方法调用比闭包调用更容易被编译器内联,从而带来显著的性能提升。

从“不可能”到“可能”——幕后的编译器修复

这个看似简单的语法限制,为何在 Go 1.18 中被加入,又为何现在可以被移除了?

答案隐藏在编译器的类型检查循环检测机制中。在早期,Go 的类型检查器为了防止无限递归(例如 type T T),采用了一套相对保守的循环检测算法。当它遇到 type T[P T[P]] 这种通过类型参数列表形成的“循环依赖”时,会直接将其误判为非法的无限递归。

NO.68162 issue的修复中,Go 团队改进了类型检查器的算法。新的算法能够更智能地区分有害的无限递归(如 type T *T)和无害的、可以在实例化时“展开”的泛型递归约束

深度剖析——Griesemer 的“两步实例化”解释

在 #75883 提案的讨论中,一个极其深刻的问题被提出:type T[P T[P]] int 这样的定义,是否会导致无法解决的循环?Robert Griesemer 对此给出了一个权威的、清晰的解释,揭示了 Go 泛型实例化的核心机制。

他指出,Go 的泛型实例化,严格遵循两个步骤

  1. 第一步:类型替换 (Substitution)
    编译器首先会简单地、机械地将调用方提供的类型实参 (type argument)(例如 int),替换掉泛型定义中的类型形参 (type parameter)(例如 P)。

    // 原始定义
    type T[P T[P]] int
    
    // 假设我们尝试实例化 T[int]
    // 第一步替换后,我们得到一个临时的、假想的定义:
    type T[int T[int]] int
    
  2. 第二步:约束校验 (Verification)
    在替换完成后,编译器才会去检查:被替换的类型实参 (int),是否满足它所对应的类型形参的约束 (T[int])?

    在这个例子中,约束 T[int] 是一个具名非接口类型。根据 Go 的类型规则,只有 T[int] 自身才满足这个约束。而我们传入的 int 显然不是 T[int]。因此,约束校验失败,T[int] 是一次非法的实例化。

这个“两步走”的过程,清晰地证明了这种递归约束并不会导致无限循环,因为类型检查总能在有限的步骤内终止。正是基于这个坚实的理论基础,Go 团队才有信心去移除最初的限制。

一个完整的带有循环引用的类型参数的示例

让我们将 Griesemer 提出的 Ring 示例,扩展为一个完整的、在未来版本的 Go 中将可以运行的程序:

package main

import "fmt"

// 1. 定义一个递归约束的泛型接口
type Ring[T Ring[T]] interface {
    Zero() T
    One() T
    Add(y T) T
    Mul(y T) T
}

// 2. 实现该接口的具体类型
type MyInt int

func (x MyInt) Zero() MyInt       { return 0 }
func (x MyInt) One() MyInt        { return 1 }
func (x MyInt) Add(y MyInt) MyInt { return x + y }
func (x MyInt) Mul(y MyInt) MyInt { return x * y }

// 3. 编写一个操作该泛型接口的通用算法
// scale computes x + y*s
func scale[R Ring[R]](x, y, s R) R {
    return x.Add(y.Mul(s))
}

func main() {
    var a, b, c MyInt = 2, 3, 5
    // 4. 调用通用算法,编译器会检查 MyInt 是否满足 Ring[MyInt] 约束
    result := scale(a, b, c)
    fmt.Printf("scale(2, 3, 5) = %d\n", result) // 预期输出: scale(2, 3, 5) = 17
}

让我们剖析一下scale 调用时的实例化过程:

main 函数中对 scale(a, b, c) 的调用,完美地展示了“两步实例化”机制是如何工作的:

  1. 第一步:类型推断与替换 (Type Inference & Substitution)

    • 编译器观察到 scale 函数的调用参数 a, b, c 的类型都是 MyInt。
    • 通过类型推断,编译器确定类型实参 (type argument) 就是 MyInt。
    • 它将 MyInt 替换掉 scale 函数签名中的类型形参 (type parameter) R。
    • 此时,scale 函数的约束被临时实例化为 Ring[MyInt]。
  2. 第二步:约束校验 (Verification)

    • 现在,编译器需要校验:类型实参 MyInt 是否满足其约束 Ring[MyInt]?
    • 要满足 Ring[MyInt],MyInt 必须实现 Ring[MyInt] 接口中定义的所有方法。让我们来逐一检查:
      • Zero() MyInt:MyInt 实现了 Zero() MyInt。满足。
      • One() MyInt:MyInt 实现了 One() MyInt。满足。
      • Add(y MyInt) MyInt:MyInt 实现了 Add(y MyInt) MyInt。满足。
      • Mul(y MyInt) MyInt:MyInt 实现了 Mul(y MyInt) MyInt。满足。
    • 由于 MyInt 完整地实现了 Ring[MyInt] 接口,约束校验通过
    • 编译器确认此次泛型函数调用是合法的,并生成相应的代码。

这个过程与我们在第四章中看到的那个非法的 T[P T[P]] int 示例形成了鲜明对比。在这里,MyInt 是一个接口实现者,它能够满足由其自身参与定义的接口约束,从而构成了一个有效的、有穷的递归

小结:Go 泛型的一次重要进化

移除泛型类型参数的循环引用限制,对于 Go 语言而言,远不止是修复了一个编译器 bug 或减少了一条规则。

  • 对开发者而言:它解锁了一种全新的、更强大、更类型安全的泛型编程模式。我们将能够构建出表达力更强、性能更高、API 更简洁的通用库和数据结构。
  • 对语言本身而言:这是 Go 泛型走向成熟的一次重要进化。它表明 Go 团队正在持续地、审慎地打磨泛型这一新特性,使其在保持 Go 哲学的基础上,逐步释放其全部潜能。

不过,CRTP 模式对于不熟悉的开发者来说,也确实存在一定的认知门槛

目前,该cl已经合并到主线,大家可以在go playground的go dev branch版本下体验。

资料链接:https://github.com/golang/go/issues/75883


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

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

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

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

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


想系统学习Go,构建扎实的知识体系?

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏,内容全面升级,同步至Go 1.24。首发期有专属五折优惠,不到40元即可入手,扫码即可拥有这本300页的Go语言入门宝典,即刻开启你的Go语言高效学习之旅!


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 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