编程与软件工程fasterthanli.me
我想逃离 Golang 的疯狂之旅（2020）
I want off Mr. Golang’s Wild Ride (2020)
2021 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 fasterthanli.me 上一篇广为流传的 Go 语言批评长文，作者通过一个需要跨平台支持的网络包开发经历，详细剖析了 Go 在错误处理、类型系统、跨平台抽象等方面的种种设计缺陷与“坑”。文章多次登上 Hacker News 首页，成为 Go 语言争议的代表性文章之一。
为什么经久不衰：它系统性地记录了 Go 在复杂场景下的真实痛点，无论你是否认同，都是理解 Go 设计取舍和适用边界的必读参考。
HN 评论精选
Go 适合快速搭建新服务，但在复杂成熟项目（尤其当年缺泛型时）会变得痛苦
我的个人经验：Go 非常适合以极低开销快速搭建新服务和工具，语言为后端设计得很好，缺少某些语言特性反而避免了其他工程师将来做出“奇怪”决定。如果你的工作是大量构建基于常见组件的新东西，Go 看起来很棒。但在成熟服务上，工程师往往需要那些特性，因为要处理极其复杂的东西。作者文中讲的包需要支持不同非 Unix 操作系统就是一例，需要管理多种对象的场景（如 Kubernetes）同理。我享受写 Go 的时光，直到 2016 年为一个创业想法写统计类应用——当时没有泛型，要么用反射，要么为各种数值类型把同一个函数实现 N 遍，这种乏味扼杀了我对这门语言的热爱。
lumost查看英文原文
My Anecdotal Experience: Golang is great for spinning up new services and tools with very little overhead, the language is well designed for the backend - and the lack of <insert programming language feature here> avoids "odd" decisions which other engineers will dislike in the future. If your job is building lots of new things using relatively common building blocks, then Golang looks fantastic! However on mature services, engineers often need <insert programming language here> because they are dealing with something extremely complex. The author of this blog post digs into the scenario for a package which needs to support different non-nix operating systems, but the same can be true of an app which has to manage many different kinds of objects (Kubernetes, or any service with many DAOs). Alternately there are engineers building all kinds of weird software which may do new things in novel simplified ways. Golang occasionally makes expressing these types of applications more difficult. Overall I enjoyed my time writing go, until I tried to write a statistics based application for a startup idea back in 2016. The project didn't get very far, and that was partly due to me getting bored having to deal with all of the different numeric data types, at the time the lack of generics made it so that you either had to use reflection - or implement the same function N times over to support the different numeric data types. This tedium killed my love of the language (I'm sure it's a better experience in 2022).
Go 的工具链和标准库无敌，但核心取舍是牺牲表达力换取可读性
Go 之所以伟大，是因为它率先在语言之外提供了出色的工具链（严格编译器、lint、不可定制的 gofmt、包管理器、优质文档、在线 playground 等）。它带来了许多后来被 Rust 借鉴的好想法，标准库也是顶级的。另一方面它更高层、有 GC，也犯过一些错误（没有和类型）。最大的取舍是缺乏表达力——新泛型可能有所帮助，但 Go 的取舍是深刻的：让写代码更难，从而让读代码更容易。
baby查看英文原文
Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.) It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed. Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured. On the other hand it is more high-level, has a GC, and has made a number of mistakes (no sum types). The biggest trade off it does though: it lacks expressiveness. The new generic will probably help, but the trade off of Golang is deep. It makes writing code harder so that reading is easier.
Go 是为特定平台和问题设计的语言，期待它改变是不切实际的
我对那些不断在 Go 身上有此领悟的人既感困惑又感同情。这就像一段虐待式的关系，人们待得太久才意识到它不会变好。我早期看过 Go，决定它不适合我：它缺少任何新语言基于过去几十年语言设计经验本该有的东西，显然是 Plan 9 一帮人为解决自己平台问题而造的，NIH 综合征的产物。多年来一直听说 Go 会加泛型且容易加好——我在 Java 泛型前后工作过，知道事后补泛型有多糟。现在 Go 终于有了泛型，很多人不满意，这毫不意外。这段关系里的伴侣不会改变，接受它然后留下，或者离开。
mcculley查看英文原文
I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better. I took a look early on at Go. I tinkered with it and decided it would not work for me. It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decades. It was clearly the result of a lot of NIH syndrome. It was built by Plan 9 guys to solve their problems on their preferred platform. For their purpose, I am sure it works just fine and is very comfortable for them. To expect it to be adapted to other kinds of problems and platforms is just wishful thinking. For years, I have been hearing that Go will get generics and that it will be easy to add and use. I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. This made me skeptical that Go with generics would be as good as it could be. Now Go finally has generics and many are not happy. This should not be surprising. This is why I see it as an abusive relationship. That partner you are so fond of is not going to change. Accept that and stay or move on.
把 Go 理解为“C 的同人小说”最能解释它的设计逻辑与局限
我听过对 Go 最精辟的描述是“C 的同人小说”。就像一群写网络基础设施软件的 C 程序员聚在一起，列了一张希望 C 有所不同的愿望清单（特指写网络基础设施的场景），然后造了一门新语言，走最直接的路径实现愿望清单，并顺理成章地继承了 C 的大部分其他特质。从这个角度看，Go 非常合理：没有未定义行为、明确定义的零值、鸭子类型、低开销的自动内存管理、易用的线程原语和轻松的跨平台构建——这是网络 C 程序员的梦想。但过去 40 年我们在语言设计上学到了很多，结合这些认知并放松 C 的约束，一门全新语言本可以做出好得多的基础设计决策。只是 Go 的设计者们似乎并不热衷于质疑他们习以为常的那些决策。
brundolf查看英文原文
The most insightful way I've ever heard Go described is as a "C fanfic". It's like a bunch of C programmers, writing software for web infrastructure, got together and made a wish-list of things they wanted to be different about C (specifically in the context of writing web infrastructure). And then they made a new language, taking the most direct path toward that wish-list, and inheriting most of C's other traits as a matter of course. Taken in this light, Go makes a ton of sense. No undefined behavior! Well-defined zero values! Duck typing! Automatic memory management with minimal overhead! Easy-to-use threading primitives and trivial cross-platform builds! A networked-C programmer's dream. But we've learned a whole lot about language design in the past 40 years, and combining those things we've learned with a loosening of C's constraints, there are much better fundamental design decisions that can be made for a greenfield language. It just seems like Go's designers weren't really interested in questioning a bunch of the ones they were used to.
问题不在 Go 本身，而在人们把它用到设计目标之外的场景
我不认为 Go 在伪装什么，它只是被自己的 popularity 所累。作者们明确说过它是为编写可扩展的网络服务设计的，他们显然不在乎 GUI、Windows、嵌入式等场景。过度热心的程序员不断把 Go 用到它不该用的地方，然后抱怨它的缺点。Go 的简单性意味着它对系统做了很多假设，我认为作者们本应更明确地说明这一点。
sally1620查看英文原文
I don't think Go lies about what it is. It is just a victim of its popularity. The authors clearly say that is designed for writing scalable networked services. And they definitely don't care about GUIs, Windows, embedded, etc. Overzealous programmers are constantly taking Go where it is not meant to be and complain about its shortcomings. Go's simplicity means that it makes a lot of assumptions about the system. I think authors should have been more upfront and explicit about this.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选