本文永久链接 – 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/08/17/create-pointer-to-simple-types

大家好，我是Tony Bai。

在 Go 中创建一个指向基本类型（如 int 或 string）的指针，为何比创建一个指向结构体的指针更繁琐？这个长期存在的“人体工程学”问题，由 Go 语言的共同创造者之一 Rob Pike 在提案 #45624 中再次带入公众视野，并由此引发了一场长达数年、充满深度思辨的社区大讨论。最终，在权衡了多种方案的利弊后，社区逐渐形成共识，Go 提案委员会倾向于接受 new(v) 语法。本文将和大家一起回顾这场关于指针初始化的“十年之辩”，深入探讨各种方案的优劣，并解读为何 new(v) 可能成为最终赢家。

背景：一个困扰开发者多年的“小”问题

在 Go 中，我们可以用 p := &S{a: 3} 这样简洁的语法，一步到位地创建一个指向已初始化结构体的指针。但如果我们想创建一个指向 int 值 3 的指针，就必须写成：

a := 3
p := &a

这种不对称性在处理大量使用指针来表示“可选”字段的场景时（例如，与 JSON、Protobuf 或 AWS SDK 交互），会变得异常繁琐。开发者往往不得不在项目中定义或引入大量的辅助函数，如：

func StringPtr(s string) *string {
    return &s
}
// 还有 Int64Ptr, BoolPtr, Float64Ptr...

正如 @adonovan 在提案讨论中通过代码分析所展示的，这种模式在 Go 开源生态中极为普遍，存在数千个这样的辅助函数和数十万次的调用。这清晰地表明，语言层面提供一个更简洁的解决方案是众望所归。

方案之争：一场关于语法、语义与哲学的辩论

Rob Pike 的提案及其漫长的讨论过程，涌现了多种解决方案，每种方案都代表了一种不同的语言设计哲学。

方案一：扩展 & 操作符

这是最直观的想法，主要有两种变体：

1. &T(v) (让类型转换变得可寻址): p := &int(3)。这是 Rob Pike 最初提出的方案之一。它利用了“类型转换必然会创建新值”这一语义，逻辑自洽。
2. &v (让非地址表达式变得可寻址): p := &3 或 p := &time.Now()。这个方案更通用，但也最危险。正如 rsc 和其他核心成员指出的，这会产生严重的歧义。例如，&m[k] 在 m 是 slice 时是取地址，但在 m 是 map 时却变成了“拷贝值并取地址”，这会引入大量难以察觉的 bug。

由于存在严重的“最小惊动原则”问题，扩展 & 的方案最终未被采纳。

方案二：引入新的泛型内建函数

随着 Go 1.18 泛型的引入，一个显而易见的解决方案是提供一个泛型辅助函数。

// 可以是内置的，也可以是开发者自己写的
func ptr[T any](v T) *T {
    return &v
}

// 使用方式:
p := ptr(3)
p2 := ptr(time.Now())

这个方案得到了许多开发者的支持，因为它无需对语言规范做任何大的改动。然而，它的缺点也很明显：

• 命名之争：应该叫 ptr, ref, addr, newOf 还是 varOf？每种名称都有其支持者和反对者。例如，ptr 和 ref 可能会让人误以为是取现有变量的引用，而不是创建一个新的拷贝。
• 标准库位置：这样一个基础的函数应该放在哪里？builtin？还是一个新的标准库包？这本身就是一个难题。

方案三：扩展 new 内建函数 (最可能的胜出者)

这是提案的核心，也是最终获得Go提案委员会青睐的方向。它同样有几种变体：

1. new(T, v)：new 接受一个可选的第二个参数用于初始化。例如 p := new(int, 3)。这非常明确，但缺点是类型 T 往往是冗余的，显得很“啰嗦”，例如 new(time.Duration, time.Second)。
2. new(v)：new 可以直接接受一个值，并根据值的类型推断出要分配的指针类型。例如 p := new(3) 会创建一个 *int。这是最简洁的方案。

new(v) 的核心争议与共识

new(v) 的主要争议在于语法歧义。当看到 new(pkg.X) 时，读者无法仅从语法上判断 pkg.X 是一个类型（new(T)）还是一个常量值（new(v)）。

然而，经过深入讨论，提案委员会认为：
* 这种歧义在实践中问题不大，因为绝大多数情况下，上下文足以让开发者区分类型和值。
* 相比于 &v 带来的严重语义混乱，new(v) 的语法歧义是次要的、可接受的。
* new 这个词本身就清晰地传达了“创建新事物”的意图，避免了 & 操作符的“拷贝还是引用”的混淆。
* 考虑到 new(T) 的使用频率远低于 &T{}，将其“回收”并赋予更强大的功能，是对语言的一次有益的“清理”。

最终，提案委员会倾向于接受 new(expr) 的形式。

new(expr) 将如何工作

根据讨论的共识，未来的 new(expr) 将遵循以下规则：

• 基本用法: p := new(3) 将创建一个 *int，其值为 3。s := new(“hello”) 将创建一个 *string，其值为 “hello”。
• 类型推断: 对于无类型常量，将使用 Go 的默认类型规则（例如，整数默认为 int，浮点数默认为 float64）。
• 显式类型: 如果需要指定不同于默认的类型，需要使用类型转换：p64 := new(int64(3))来创建一个int64类型变量p64，而不是默认的int指针类型变量。
• 无上下文类型推断: new(v) 不会根据赋值的上下文来推断类型。例如，var p *int64 = new(3) 将会编译失败，因为 new(3) 的类型是 *int，不能赋值给 *int64。

结论：小改动，大便利

从 Rob Pike 最初的提案，到社区长达数年的激烈辩论，new(v) 的最终可能胜出是 Go 语言演进过程的一个缩影。它通过一个微小但精心设计的语法扩展，解决了困扰社区多年的一个普遍痛点。

这个决策过程本身，也充分体现了 Go 团队的设计哲学：

1. 优先考虑语言的一致性和无歧义性，因此拒绝了看似更简洁但充满陷阱的 &expr 方案。
2. 在不破坏兼容性的前提下，勇于重塑旧有特性，将使用率不高的 new 重新利用，赋予其更强大的生命力。
3. 充分倾听并分析社区的真实数据，@adonovan 的大规模代码分析为该功能的需求提供了强有力的数据支撑。

虽然我们仍需等待该提案在未来某个 Go 版本中正式落地，但可以预见，当它到来时，我们代码库中那些重复的 Ptr 辅助函数将成为历史。这正是 Go 语言持续进化、不断提升开发者幸福感的魅力所在。

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

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

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

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

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

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