编程与软件工程teamten.com
我为什么不喜欢 Go 语言（2016）
Why I Don't Like Golang (2016)
2018 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Lawrence Kesteloot 于 2016 年写的批评 Go 语言的文章，列举了未使用变量报错、隐式接口实现、缺少三元运算符、日期格式化设计等让他不满的语言特性。文章多次登上 Hacker News 首页，引发关于 Go 设计取舍的长期讨论。
为什么经久不衰：它系统性地指出了 Go 的设计争议点，而其中部分问题（如接口隐式实现）至今仍未解决，是理解 Go 优缺点争论的经典参考。
HN 评论精选
认同文章结论：Go 只适合小型简单程序，大型复杂项目会被类型系统拖累
如果说我最想强调的是文章的结论：如果你的程序较小、主要描述它做什么，Go 没问题；但如果程序很大、有复杂的数据结构，或要处理大量外部数据，类型系统会毫无益处地与你作对，你最好换用类型系统有帮助的静态语言，或类型系统不碍事的动态语言。这比我用了一年 Go 后的感受表达得更好——我最终觉得它像 Java 的一个类 Pascal 子集，带着前者的种种缺陷。
wwweston查看英文原文
If there's anything I'd draw the most attention to from this, it'd be the conclusion: "If your program is small and can mostly be described by what it does... then Go is fine. If it’s large, if it has non-trivial data structures... or if it will be dealing with a lot of data from the outside, then the type system will fight you for no benefit and you’re better off using a different static language (where the type system helps) or a dynamic language (where it doesn’t get in your way)." That's a much better way to express my sense after almost a year of working with it that I'd ended up with a Pascal-like subset of Java with most of the liabilities of the former. And I wanted to like it going in ("hey, some people love it, and it's more or less Gosling's statement about Java w/o classes come to life!").
生产环境多年使用者的反驳：文中批评的问题实际影响很小，工具链优秀
我从 2015 年起在生产环境用 Go，除了三元运算符，文中这些问题没一个对我构成大困扰。我主要做 REST API 开发，从未因大小写或接口实现问题受阻，工具链是我用过最好的之一。当然 Go 并不完美：goroutine 里的 panic 有时很难追踪，从 Glide 到 dep 再到 go mod 的依赖管理迁移也很折腾。但如果让我选，我不会回到 Java、C#、PHP 或 NodeJS。我的服务器端首选是 Go 和 Elixir。
losingthefight查看英文原文
I have been using Go in production since 2015 and can honestly say that other than the ternary operator, none of these have been a major issue for me. Granted, I am doing mostly REST API development so my use cases may be different, but I have never had an issue with capitalization or which interfaces are implemented. The tooling is by far some of the best I have used in a language. Paired with a good editor (I personally use VS Code on Ubuntu 18.04 as my main setup) and I have yet to miss exceptions or wonder what my code is capable of doing. That being said, Go isn't perfect by any stretch. Sometimes panic ins Go routines can be very hard to trace. The transition to Go modules is challenging for larger projects with versions beyond 1.x (when I started it was Glide, then dep, now go mod, which has been a bit frustrating). However, I wouldn't go back to Java, C#, PHP, or NodeJS if I had the choice. My go to in the server space is Go and Elixir. I don't feel a desire or need for anything else, but again, that's me. You know your use case better than a stranger on the internet :)
2022 年视角：部分问题已修复，但隐式接口实现仍是未解决的真实痛点
导入/模块问题已修复到可用且大幅改善的程度，泛型也加上了。但文章提到的结构体不显式声明实现了哪些接口的问题确实存在且未解决，在大型代码库中尤其麻烦。据我所知唯一能查找接口实现的工具是 GoLand，价格不菲。搞清楚一个 API 需要什么类型不应该要求读完包里的每一行代码，这拖慢了每个大型 Go 项目的开发者。
implying查看英文原文
They've fixed the import / modules situation to a point where it's usable and much improved, and generics have been added. However, the issue this brings up about structs / types not explicitly declaring which interfaces they implement is a real and unaddressed problem, especially in large codebases. The only tool that I'm aware of that finds implementations is GoLand, at steep JetBrains prices. Figuring out what type an API is asking for should not require reading every line of code in the package, and slows down every developer of large Go projects
语言超出原始设计规模且未优雅演进，作者甚至为此改过编译器
这篇文章写于 2016 年，但依然切中要害。即使是中等规模的项目，我也被其中许多问题坑过。对一个号称拒绝魔法的语言来说，这里面的魔法实在太多了。每个未使用的导入和变量都报错中断编译尤其烦人，我甚至为此给 Go 编译器打了补丁把它们改成警告。归根结底，我认为问题在于这门语言超出了它最初的设计规模，而且（至今）没有优雅地演进。
kstenerud查看英文原文
This article is from 2016, but it's still relevant. Even in medium sized projects I've been bitten by many of these issues, and for a language that's supposed to eschew magic, there's an awful lot of wizardry going on. Stopping compilation with an error for every unused import & variable is particularly annoying, so much so that I've patched the go compiler to treat them as warnings instead [1]. Ultimately, I think the problem boils down to a language that outgrew its original design, and hasn't evolved elegantly (yet). [1] https://github.com/kstenerud/go
历次讨论
同类还值得读
开源应用架构
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编辑精选