为什么 Go 是 AI 辅助编程的理想语言
Why Go Is an Ideal Language for AI-Assisted Software Engineering
软件开发正经历从“手写代码”到“审查代码”的根本转变。当 AI 能瞬间生成大量代码时，语言的核心价值不再是编写效率，而是可读性、一致性和可维护性。Go 语言凭借其“平台化”设计、强制统一的代码风格（gofmt）、强大的静态类型系统以及永不破坏向后兼容性的承诺，成为 AI 协作时代的理想选择。Go 的标准化生态不仅让人类开发者更易协作，也为 LLM 提供了高质量、低噪声的训练数据，使 AI 能更精准地生成、验证和修复代码，从而构建出长期可靠且易于演进的软件系统。
在 AI 驱动的开发时代，软件开发生命周期的瓶颈已从代码生成完全转移到了代码验证。
HN 评论区
499- jeanbza
完全同意这篇文章的观点。
在 Netflix，我负责 Go 语言小组。我们注意到越来越多的报告指出，用户发现他们的 AI 代理编写的 Go 代码比其他语言更好，同时也有越来越多的项目倾向于选择 Go 而非其他语言。
我再补充两点：
- Go 拥有非常优秀的编写高质量代码的资源，包括 https://go.dev/doc/effective_go 和 https://google.github.io/styleguide/go/ 这两个宝库。补充：抱歉忘了提，我们会把这些资源提供给 AI 代理，它们利用这些资源能产出更优质的 Go 代码。
- 对于语言团队来说，Go 简直是梦想之选。`go fix` 工具、AST/SSA 包、`go.mod` 的读写便捷性（如 go mod edit 等），以及各种其他“平台级”特性，使得大规模修改 Go 代码比其他语言容易得多。
- CoolestBeans
我讨厌这篇博客试图玩弄的障眼法。Go 写起来不好玩又怎样？反正现在都是 AI 在写了！是啊，所以过去二十年它一直很难用？我知道文章的主要论点是 Go 在软件工程整体上是好的，因此它作为编程语言本身的弱点被最小化了。我也提出过类似的论点，认为编码代理将负担转移到了软件工程的其他方面。但是，大家不都看穿 Google 在这里想干什么吗？他们想宣称规则已经改变，这样 Go 的弱点就能转化为优势。我不买账。
- Havoc
如果这话不是出自 Go 语言创造者之口，可能会更可信一些。
我个人在 LLM 方面更倾向于 Rust。那种挑剔的编译器和在编译时暴露错误的能力，对我来说对 LLM 简直完美。用 Token 去硬刚编译错误，远比试图推断运行时哪里会出错并试图通过测试来捕获要好得多。
Token 很便宜，运行时的意外可不便宜。所以我想要一个超级较真的编译器。我也看过 lean4，觉得它是逻辑上的下一步，但我对自己能否足够熟练地引导 LLM 使用它缺乏信心。
- CopyOnWrite
我不同意。
即使是针对非常简单的情形，LLM 也生成不出无 bug 的并发代码。
Golang 缺乏构建良好抽象的能力，更别提那些非微服务所需的额外工具和库简直就是狂野西部。
对我来说，LLM 允许人们更快地生成更多糟糕的 Golang 代码是一个危险信号。这仅仅是为了那些负担得起足够多软件工程师的公司做优化，这些工程师需要审查为了解决那些在其他优秀编程语言和/或框架中内置就能解决的琐碎问题而编写的海量代码。
使用 LLM 时，请使用合适的编程语言。这可能是 Golang，但更可能是 C#、Java、Python、Ruby，甚至是 PHP。（或者是 Rust、C、D 等……）
- woggy
我认为，适合代理式编程的正确语言，应该是那种能从形式化验证中引入更多理念的语言，让规范和可执行代码存在于同一个世界中。我不太清楚那具体会是什么样子，但这只是我这个非专家的一种直觉。规范可以用一种更高级的语言（不是英语）编写，并在编译时验证底层代码。我认为目前 Dafny 可能是最接近的选择。
- dgunay
我喜欢 Go，但当你加入代理的规模和典型使用模式后，其中一些所谓的“优势”就大打折扣了。
| Go 易读 / Go 易维护
确实，作为一种低魔法语言，Go 在不同项目间的代码看起来非常相似，这对于可靠地理解依赖项的源代码来说非常棒。而且它的工具链是世界级的。我很欣赏 Go 的这一点。
但在实践中我发现，在拥有多个团队的单体仓库中工作，那些不把跨团队可读性作为优先级的贡献者，往往会写出多得多的代码。而且对于业务逻辑来说，如果我无法理解更广泛的上下文，无法知道某个操作可能会产生“隔空取物”般的影响，那么我能逐行读懂代码这一事实也无济于事。
在代理出现之前，我见证了一个快速转变：代码库从大部分能装在我脑子里，变成了被反复编写和重写，直到我完全认不出来。现在我们有了代理，由于它们在宏观软件工程方面仍然大多不够出色，如果没有在其他方向上付出协同努力，代码库中的知识债务积累（当然还有技术债务积累）的速度将加快十倍。Go 易读这一特性本身并不能从根本上解决这个问题。
- Myrmornis
> 通过内置的 gofmt 工具强制采用单一、标准化的格式
在我开始使用 Go 之前，我就读过很多次关于这一点的内容，所以当我发现这其实是个谎言时，我感到特别失望。代码格式化工具最重要的任务是换行长代码行，但它做不到。它甚至没有提供这样的选项！
- imranq
Google 内部甚至不使用自己的 Go 构建系统。他们全用的是 blaze / bazel，所以他们甚至没有利用 Go 所谓的编译器反馈。另外，如果语言是为代理而非人类设计的，那么 Go 的冗长是否对代理有帮助，目前尚不清楚。
- Buttons840
我会争辩说，Go 并不处于“帕累托前沿”，而且无论你如何评估编程语言的各个属性，公平的评估永远不会选中 Go。
一个简单的例子是：如果你高度重视语言流行度；Go 并不是最流行的。如果你高度重视能捕获错误的类型系统；Go 的类型系统捕获的错误比其他语言少。等等。没有任何一种属性的加权求和能选中 Go——这就是我的论点。
- osigurdson
如果你必须学 Go，或者想学 Go，那就去学吧。否则，我认为没有任何理由去学。我同意它易读，但不如你已经掌握的语言易读。