编程与软件工程fasterthanli.me
我们为继续使用 Golang 而对自己说的谎
Lies we tell ourselves to keep using Golang
2022 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章列举了开发者为了继续使用 Go 而对自己说的种种“谎言”，并逐一反驳，认为 Go 在生产服务中并不合适，Rust 是更好的选择。文章语气尖锐，引发争议，在 Hacker News 上多次被讨论甚至被举报。
为什么经久不衰：它触及了工程选型中“简单易用 vs 类型安全”的核心矛盾，无论你站哪边，都能从中获得关于语言设计和团队生产力的思考。
HN 评论精选
同意文章写得好但反对其结论，认为Rust的复杂度和决策成本让Go在团队生产中更实用。
作者文笔好，论点有力。他的“我想下Go先生的过山车”文章也不错。但我不同意他的立场，即“你不应该用Go做生产服务”（他在某篇Go文章里明确说过）。更好的替代品是Rust。行吧，我承认在列举的例子中Rust处理得更好。但Rust不是万灵药。Rust复杂且难，为了理论上处理很少发生且更少造成问题的场景而承担这个负担往往不值得。编程是达到目的的手段，使用Rust的成本（招聘、开发时间增加）往往不划算。Go成功是因为它容易让不同水平的团队解决生产问题。标准库功能齐全，生态好。通常只有一种正确做法。Rust则不然。比如，生产代码里做一个web请求非常常见。Go里不用争论，用标准库就行。Rust里你得用一个crate，这需要做决定。更糟的是异步，Rust里你得决定用Tokio还是别的。这个负担在Go里不存在。顺便说，这篇文章不该被举报，人们举报它很可悲。
HL33tibCe7查看英文原文
The author writes well and makes compelling points. His "I want to get off Mr Golang's Wild Ride" post is good too. But I don't find myself agreeing with his position, which is "you shouldn't use Go for production services" (he explicitly says this in one of his Go posts, I forget which one and don't have time to look right now). The better alternative to Go is Rust. Okay, sure, I'm willing to admit that in the examples presented, Rust handles things better. But Rust isn't a panacea. Rust is complicated and hard, and often it's not worth taking on that burden just to theoretically handle cases that rarely occur and even more rarely cause any problem. Programming is a means to an end, and the cost of using Rust (hiring, increased development time) is often not worth it. The reason Go is successful is because it's easy for companies to use to solve production problems with teams of varying expertise. Its stdlib is well-featured, its ecosystem is good. There's generally one correct way of doing things. The same doesn't appear true in Rust. For example, an _incredibly_ common thing to do in production code is to make a web request. In Go, there is no need for debate, you use the stdlib. In Rust, you have to use a crate, which requires a decision to be made. Even worse is the async story, in Rust you have to decide whether to use Tokio or whatever. That burden is just not present with Go. Btw this article should not be flagged and it's pathetic that people have flagged it.
批评HN用户举报文章的行为，认为这是对不受欢迎观点的审查，违背理性讨论精神。
举报这篇帖子是对不受欢迎观点的可耻审查。你可以说是讽刺/愤怒/沮丧导致被举报，但我怀疑如果话题不同就不会被举报。假定作者是为了互联网博客积分而在做恶意论证，违背了HN的精神。我更喜欢自己下结论。我通常期望HN能冷静理性地反驳内容，但今天不是。
rmasters查看英文原文
Flagging this post strikes me as shameful censorship of an unpopular opinion. You may say it's the snark/anger/frustration that got flagged, but I suspect it would not have been flagged if the topic were different. Presuming the author is making bad-faith arguments for internet blog points goes against the spirit of HN. I prefer to draw my own conclusions, thank you. I normally expect HN to take the higher ground with calm and reasoned counter arguments of the content but not today I guess.
从Go转向Rust后更欣赏Rust的类型系统，但认为作者理想化，学习成本让很多人不会切换。
我在专业和业余项目里都用过Go和Rust，先用的Go。刚用Go时觉得“哇，好简单容易”，没意识到自己在忍受这门语言。学Rust相对难些，但一旦学会并用Rust写了些非平凡程序，就像大脑里一条之前堵住的路打开了，再回到Go时，痛苦地意识到程序员必须记住的问题（或者写大量样板代码来跟踪）。这些问题Rust的类型系统直接解决。Go里nil能渗入代码库，FFI很差，这让我以后不会选它做项目。我个人对修改别人写的Go代码没信心，除非每行都懂，否则不敢接受PR。Rust在这方面令人耳目一新。不过，作者有点理想化。从手工解决问题到写程序自动化，Go和Rust很接近。一旦有人学好Go，再学Rust或思考Rust解决的问题的增量成本就不值得了。这很可悲，但就是这样。
blindseer查看英文原文
I've used Go and Rust professionally and in side projects, and I had used Go first before Rust. When I first used Go, I was like "oh wow, this is so simple and easy", and I didn't realize that I was putting up with the language. Learning Rust was relatively harder, but once I did and wrote some non trivial programs in Rust, it was like a pathway in my brain opened up and was previously blocked, and then when I went back to Go, I was painfully aware of issues that I the programmer had to keep in mind (or write a LOT of boilerplate code to keep track of). Issues that Rust's type system just solves. The way `nil` can seep into your codebase in Go and how bad the FFI is in Go will prevent me from ever choosing it for a project going forward. And I personally would not feel confident modifying Go code written by someone else, and would not feel confident accepting PRs into my Go codebase unless I understood every line inside and out. Rust is a breath of fresh air in that regard. All that said, I think the author here is idealistic in a certain sense. In the scale of "solving a problem by hand (or using Excel/a proprietary tool etc)" to "writing a computer program to automate it", both Go and Rust are very close to each other. And once someone learns Go and knows it well enough, the incremental cost of learning Rust or even thinking about the problems Rust solves for you becomes not worth it. I think that it's sad that this is the way it works, but that's just how it is. It's easy for settle for a local optima like Go when taking into consideration family, pets, salary, time, effort etc. I do think on a long enough timescale, programmers will eventually move to a "better" language. But in my opinion, that time scale exceeds the lifespan of a human :)
强调生产力和交付价值，认为语言设计问题对大多数人不重要，劝人放弃Go是糟糕建议，尤其对新手。
上一篇我不在乎，这篇也不在乎。我在乎我的生产力，我团队的生产力，以及把东西发出去。这些是我在乎的，Go非常适合。如果你也在乎这些，而且你在用Go，你不应该停止用Go。我整个职业生涯都有人告诉我别用我用来高效工作的语言或工具。我建过成功的公司，所有东西都用Python写，而HN上一直有人说我用低级语言因为空格有意义或字符串默认不是unicode之类。如果你在乎别的，行。如果你觉得Go不适合你，别用。但别因为晦涩的语言设计问题或人们日常很少遇到的API选择就告诉用Go（和其他生产力语言）的人停止使用。这对大多数人来说不重要，而且是糟糕的建议。问题在于HN上有很多经验不足的人（就像我当年）会把这篇文章记在心里，但除了觉得自己是用烂语言烂开发者之外，没有任何可操作的东西。他们不是，他们也不是。
streblo查看英文原文
I didn't care in the last post and I don't care about this one either. I care about my productivity, I care about my team's productivity, and I care about getting stuff shipped. Those are the things I care about, and go works great for that. If you care about those things too, and you're using go, you shouldn't stop using go. My whole career people have been telling me to stop using languages or tools I've been productive with. I've built successful companies where everything was written in python, the whole time people on HN telling me how I was using a lowly language because of things like whitespace significance or strings that were not unicode by default. If you care about other stuff, fine. If you don't think go works for you, don't use go. Just stop telling people who are using go (and other productive languages) to stop using them because of obscure language design issues or obscure API choices that people rarely encounter day to day. That isn't what matters to most people, and it's actually bad advice. The problem is that there are a ton of less experienced people reading stuff on HN (just as I once was) who will take this to heart but have nothing actionable to gain from it, except to think they're a bad developer using a bad language. They aren't, and they're not.
历次讨论
同类还值得读
开源应用架构
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编辑精选