指针 - Tony Bai

本文永久链接 – https://tonybai.com/2025/10/11/go-is-a-good-first-programming-language

大家好，我是Tony Bai。

近日，在 r/golang 社区，一个初学者的真诚提问，再次点燃了一场关于 Go 是否适合作为入门语言的激烈辩论。他很困惑：“为什么很多经验丰富的开发者说 Go 不适合作为第一门编程语言，而很多大学却用与之相似的 C 语言作为第一门编程语言呢？”

这个问题，如同一块探针，深入到了编程教育的核心分歧之中，并迅速将社区观点分裂为两大阵营。一方认为，Go 能从第一天起就培养严谨的工程思维，堪称“天才之选”。另一方则认为，它的定位不上不下，对初学者而言是一个“糟糕的开端”。

那么，真相究竟为何？为了厘清思路，让我们深入这场辩论，分别听取两大阵营的观点，并审视其背后的根本分歧：我们学习编程，到底是为了什么？

观点一：Go 是一个“糟糕的开端”

这一方的核心论点是：Go 语言陷入了一个尴尬的“中间地带”，对于编程教育的两个主要目标，它都未能完美胜任。

论据一：Go 不够底层，无法胜任“计算机科学基础教育”

这一方的支持者指出，大学 CS 教育的首要目标，是培养学生对计算机工作原理的深刻理解。在这个目标下，C 语言之所以是“黄金标准”，恰恰在于它的“不友好”：

直面内存：手动 malloc/free 和危险的指针算术，迫使学生直面内存布局、栈与堆等核心概念。
最小化抽象：学生必须从零开始构建数据结构，这个过程能让他们对算法的理解建立在物理实现之上。

而Go 的垃圾回收 (GC) 机制，虽然是工程上的巨大进步，但在教育上却成了一个“黑盒”，完全隐藏了内存管理的复杂性。它让学生“知其然”，却无法“知其所以然”，因此无法胜任传授底层原理的重任。

论据二：Go 不够“温柔”，无法胜任“快速入门与兴趣培养”

接着，这一方展示了另一个极端——以 Python 为代表的“实战派”入门语言。这类语言的目标是让初学者尽快体验到编程的乐趣和效用。

语法“温柔”：Python 的语法接近伪代码，极大地降低了入门的认知门槛。
快速反馈：作为解释型语言，其“编写即运行”的交互式体验，对维持初学者的学习热情至关重要。

尽管 Go 也以简单著称，但其静态类型、编译周期、以及对项目结构的规范要求，都为纯粹的初学者制造了不必要的“摩擦力”。与 Python 相比，它不够“温柔”，可能会在入门阶段就劝退一部分学习者。

由此来看，Go 既不像 C 那样能让你深入底层，又不像 Python 那样能让你轻松起步。它是一个尴尬的“中间派”，对于任何一个明确的教学目标来说，都有比它更好的选择。因此，它是一个“糟糕的开端”。

观点二：Go 是一个“天才之选”

另一方的核心论点是：观点一中所说的“中间地带”并非尴尬，而是一个经过深思熟虑、精心设计的“甜蜜点” (sweet spot)。Go 的目标，不是培养纯粹的理论家或业余爱好者，而是从第一天起，就为培养专业的“软件工程师”奠定基础。

论据一：Go 教授的是“更重要”的底层原理

观点二的支持者承认 Go 隐藏了手动内存管理的细节，但他们认为，在 2025 年的今天，这部分细节的教学价值正在下降。相反，Go 教授了更现代、更重要的底层概念：

安全的指针哲学：Go 保留了指针，让学生能够深刻理解“引用 vs. 值”这一核心概念，这是理解程序性能和行为的关键。同时，它通过移除指针算术，杜绝了 C 语言中最常见的一类安全漏洞。
并发是第一性原理：他们强调，现代计算的核心是并发。Go 将 goroutine 和 channel 作为内建特性，让学生能够以一种前所未有的简洁方式，去接触和理解并发这一现代计算机科学的基石。

Go 并非不教底层，而是有选择地教授那些在现代软件工程中依然至关重要的底层概念，同时将那些日益自动化、易出错的细节（如手动内存管理）抽象掉。

论据二：Go 的“摩擦力”恰恰是良好工程习惯的开端

观点二的支持者认为，观点一所说的“摩擦力”，实际上是宝贵的“纪律训练”：

静态类型：不是负担，而是一张安全网，它教会学生思考数据的结构和契约。TypeScript逐步超越JavaScript就是一个静态类型取得胜利的明证。
显式错误处理：if err != nil 不是样板代码，而是对健壮性最深刻的、日复一日的训练。它让学生明白，失败是程序中正常的一部分，必须被认真对待。
编译周期：不是障碍，而是专业开发流程的预演，教会学生区分构建时和运行时。

Go 的设计，完美地平衡了抽象与细节。它既能让学生快速构建出实际的应用（比如一个简单的 Web 服务器），又在整个过程中不断地、潜移默化地向他们灌输专业的工程思想。它不是在教“编程”，而是在教“软件工程”。因此，对于立志成为专业工程师的学习者来说，它是一个“天才之选”。

小结：目标决定了最佳路径

至此，辩论的脉络已经清晰。这场争论没有绝对的赢家，因为双方的论点都建立在各自合理的目标之上。

最终的结论是：这取决于你的目标。

如果你的目标是成为一名计算机科学家，深入理解机器的每一个齿轮如何运转，那么从 C 开始的“苦修”或许无法绕开。
如果你的目标是快速体验编程的乐趣、尽快构建应用，那么 Python 或 JavaScript 可能会为你提供一条更平坦、更愉悦的道路。
而 Go，则为那些从一开始就立志于成为一名专业、高效、能构建并发系统的现代软件工程师的学习者，提供了一条无与伦比的捷径。

它或许不是最完美的“第一站”，但对于目标明确的人来说，它是一个能让你赢在起跑线上的“天才之选”。它将“学习编程”与“成为一名软件工程师”这两个阶段，以前所未有的方式紧密地结合在了一起。

资料链接：https://www.reddit.com/r/golang/comments/1nvbrv8/im_confused_as_to_why_experienced_devs_say_go_is/

想系统学习Go，构建扎实的知识体系？

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

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

本文永久链接 – https://tonybai.com/2025/09/27/direct-ref-to-embedded-fields-in-struct-literals

大家好，我是Tony Bai。

在 Go 语言中，结构体嵌入 (Embedding) 是一个强大而独特的特性，它为我们提供了一种优雅的“垂直组合”方式。然而，多年来，它的使用体验中一直存在一个广为人知的“反直觉”之处，一个让无数开发者（包括 Go 核心团队成员自己）都曾踩过的坑。

近日，一个旨在解决此问题的、长达十年的“陈年”提案（#9859）被重新激活并进入了活跃评审阶段(active)。这预示着 Go 结构体字面值的使用方式，可能即将迎来一次意义深远的简化。在本文中，我就和大家一起对该提案做一下解读，看看新提案究竟解决了什么问题，一旦落地后，究竟会给Go开发者带来哪些好处。

核心痛点：不对称的读写行为

让我们从问题的核心开始。假设我们有如下定义：

type Point struct {
    X, Y int
}

type Circle struct {
    Point // 嵌入 Point
    Radius int
}

在 Go 中，我们可以通过“字段提升”(Field Promotion) 的特性，非常自然地访问被嵌入的字段：

var c Circle
c.X = 10 // 直接访问，非常直观
c.Y = 20

然而，当我们尝试在结构体字面值中初始化这个 Circle 时，同样的直觉却会碰壁：

// 编译失败！
// c := Circle{X: 10, Y: 20, Radius: 5} 

// 必须使用冗长的嵌套方式
c := Circle{Point: Point{X: 10, Y: 20}, Radius: 5}

这种读写行为的不对称性，正是 #9859 提案试图解决的核心痛点。该提案建议，允许开发者在结构体字面值中直接引用嵌入字段，使得初始化过程与字段访问过程保持一致和直观。

如果该提案被接受，下面的代码将变得合法：

// 提案期望的写法
c := Circle{X: 10, Y: 20, Radius: 5}

正如 Go 团队的 Brad Fitzpatrick 所言，他与提案发起人 Andrew Gerrand 都曾独立地“踩过这个坑”，并都下意识地认为 Circle{X: 10, …} 这种写法本就应该可行。

实际上，这并非 Go 语言首次修正其复合字面值中的“不对称”设计。一个惊人相似的历史先例，便是 Go 1.5 版本对 map 字面值的简化。

在 Go 1.5 版本之前，一项允许在切片字面值中省略元素类型的规则，由于官方文档中所称的“一个疏忽”(an oversight)，并未被应用到 map 的键 (map keys) 上。这意味着，当时初始化一个切片可以很简洁，但用结构体作为键来初始化 map 却显得十分冗长。

在 Go 1.5 之前，你必须这样写：

m := map[Point]string{
    Point{29.9, 52.8}: "Persepolis",
}

Go 1.5 之后，编译器被赋予了根据上下文推断键类型的能力，代码得以简化：

m := map[Point]string{
    {29.9, 52.8}: "Persepolis",
}

这两个场景的核心思想如出一辙：都是在复合字面值 (composite literal) 的上下文中，当编译器能够明确推断出所需类型时，允许开发者省略冗余的类型声明，从而提升代码的简洁性和语言的一致性。

从这个角度看，#9859 提案可以被视为 Go 语言在其设计哲学上，追求更高层次一致性的又一次重要尝试。

争议焦点：当嵌入字段是指针时，会发生什么？

这个看似简单的提议，在其长达十年的讨论中，之所以进展缓慢，是因为它触及了一个极其棘手的边缘情况：当嵌入的字段是一个指针时，该如何处理？

type Point struct {
    X, Y int
}

type Circle struct {
    *Point // 嵌入 Point 的指针
    Radius int
}

现在，当我们尝试 Circle{X: 10, …} 时，*Point 字段本身是 nil。对 nil 指针的字段进行赋值，在常规的赋值语句中 (c.X = 10) 会导致一个运行时 panic。

那么，在结构体字面值中，编译器和运行时应该如何表现？Go 核心团队成员 Ian Lance Taylor 系统性地提出了三种可能性，这也构成了整个提案讨论的核心：

隐式分配指针 (Silently allocate the pointer)：在初始化 X 字段时，自动为 *Point 分配内存（即 new(Point)）。
运行时 Panic (Panic at run time)：与常规赋值语句的行为保持一致，在运行时因空指针解引用而 panic。
编译期错误 (Give a compilation error)：编译器静态地检测到这种情况，并直接报错。

深层权衡：便利性、一致性与安全性

这三种选择，代表了在语言设计中不同的哲学权衡：

选项一：隐式分配 (便利性优先)

优点：对用户最友好，提供了最流畅的体验。复合字面值的存在就是为了让事情变得更简单。
缺点：
- 隐藏了内存分配：这与 Go 语言推崇的“显式优于隐式”的哲学相悖。一次看似简单的赋值，背后可能隐藏着一长串的指针分配 (Foo{Bar: &Bar{Baz: &Baz{…}}})，这会让性能分析变得困难。
- 破坏封装性：一个由 Jonathan Amsterdam 提出的“杀手级”论据指出，如果一个包导出了一个嵌入了私有指针类型的结构体，隐式分配将允许包外的代码做到一些本不该做到的事（分配这个私有类型），从而破坏了封装。

选项二：运行时 Panic (一致性优先)

优点：由 Go 语言之父之一的 Robert Griesemer 提出的观点，他认为应该遵循一个简单的规则：如果一系列赋值语句 var x T; x.f1=v1; x.f2=v2; … 是合法的，那么结构体字面值 T{f1:v1, f2:v2, …} 也应该是合法的，并且语义相同。这最大程度地保证了语言行为的一致性。
缺点：将一个本可以在编译期发现的问题推迟到运行时，降低了代码的安全性。

选项三：编译期错误 (安全性优先)

优点：最安全的选择，将潜在的 panic 在编译阶段就彻底消除。
缺点：
- 体验不佳：这可能会激励开发者为了获得更简洁的初始化语法，而避免使用指针嵌入，即便指针嵌入在设计上是更合理的选择。
- 增加了语言规则的复杂性：“当嵌入的是值时可以，是指针时不行”，这会让规则变得不那么统一。

我个人比较倾向于选项2，并认同Robert Griesemer的“一致性优先”的观点，即使这可能会将问题推迟到运行时：

type E struct {
    A int
}

type T struct {
    *E
    B int
}

func main() {
    // 当前合法的语法
    t1 := T{}
    t1.A = 5 // panic
    t1.B = 6
    fmt.Println(t1)

    // 提案新语法
    t2 := T{
        A: 5,    // panic，与提案前保持语义行为一致
        B: 6,
    }
    fmt.Println(t2)
}