编程与软件工程kristoff.it
为什么选 Go 而不是 Rust
Why Go and Not Rust?
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章结合自己的项目选择，比较 Go 与 Rust，解释为什么在不少工程场景里选 Go 而不是 Rust：Go 简洁、编译快、易上手，团队协作和长期维护成本较低；Rust 的类型系统和底层控制更强，但学习和认知负担更高。文章并非简单断言谁全面更好，而是讨论两种语言适合不同的问题、团队和规模。
为什么经久不衰：它把语言选型从“哪个更强”拉回到“简单、团队能力与项目规模”这些长期有效的工程权衡上，因此多年后仍值得读。
HN 评论精选
“简单”有歧义：Go 特性少不等于用起来容易，超出适用规模后反而更不简单。
我不反对这个观点，但我不喜欢用“简单”描述语言，因为它有两个意思：组成部件少，和容易使用，而这两者并不相同。Go 有些地方并不容易（不简单），因为它的语言特性少（简单）。Go 入门门槛确实更低，在某些规模和复杂度的项目上生产力很高；但当你开始超出 Go 所设计的“规模”时，它用起来就不那么简单了。要体会泛型、非空类型、无共享可变状态等特性的价值，你得先遇到需要它们的问题，那时这些额外特性才划算，能让开发和维护更容易。
pornel查看英文原文
Not disagreeing with the sentiment, but I dislike the word "simple" used to describe languages, because it has two meanings: simple = "consists of few parts" and simple = "easy to use", and these are not the same. Certain things in Go are not easy (not simple), because Go has few language features (is simple). Go has definitely a lower barrier to entry and is very productive for certain size and complexity of a project. However, as you start pushing beyond "scale" Go is designed for, Go becomes less simple to use. To appreciate things like generics, non-nullable types, no shared mutable state, you have to be working on a problem that requires these things, and only then these extra features pay off and make development and maintenance easier.
缺少泛型会让某些数据结构代码臃肿；Rust 的迭代器和类型系统在复杂数据转换上更舒服。
作为现在的 Rust 爱好者和以前的 Go 爱好者（大约 6 年），这篇文章说到我心坎里。我们公司技术债很多，我通常先问：这程序你会用 C++ 还是 Python 写？再据此推荐 Rust 或 Go，并补充看数据结构和类型转换的频率。最近把一些大型 Go 程序转成 Rust 后，我发现有些程序完全适合 Go，但没有泛型写起来很痛苦：我的一个程序工作不复杂，却涉及很多不同数据结构，用 Go 写很不舒服。Go 有了泛型可能会好一些，但这只是移动门槛；某些问题用更高级的类型系统会更友好（虽然也更复杂）。我很期待 Go 能通过泛型获得基本的迭代器行为。Rust 里最小的一些东西对我却是最大的解脱；在 Go 里把 [][]T 从一种类型转成另一种很麻烦，而迭代器对短小易读的实现影响巨大。根据我的经验，Go 最大的缺点是“简单”带来的代码膨胀：一个简单目标可能变成多个函数的实现，代码局部性变差，突然就不简单了。
asdkhadsj查看英文原文
As a now Rust lover and prior (6 years?) Go lover, this article hits home. We have a lot of tech debt in my shop (who doesn't lol), and generally I advocate Rust or Go. I usually start the conversation with: Would this be a program you'd write in C++ or in Python? And then I advocate Rust or Go, with one amendment; data structures, and frequency of conversion/etc. Having converted some large Go programs to Rust recently I now have the perspective that some programs, while perfectly fit for Go, are miserable to write without Generics. I had a program which did some pretty minor work, but it did so with a lot of varying data structures and writing it in Go was less than pleasant. No, Go might handle this better with generics. However I imagine this will only move the bar. Certain problems are just going to be friendlier (though, more complex!) to solve with a more advanced typing system. I do look forward to the day that Go can get basic iterator behavior via Generics (if ever). Some of the smallest things in Rust were the biggest sighs of relief for me. Converting a slice of slices from one type to another is just a PITA in Go (in my opinion), and iterators make a world of difference for short, easy to read and comprehend implementations. In my experience, Go's biggest fault is code bloat that "simplicity" offers. A simple goal could turn into a multi function implementation in Go that frankly shouldn't have to be. Then code locality gets worse over time, and suddenly simple doesn't feel simple. Rust's larger complexity (iterators and the like) improve code locality, and thusly simplicity, in my experience. It's a game of tradeoffs. They're both great languages, and they both have their places in my company.
Go 与 Rust 面向不同市场；Go 并非真正简单，GC 也有复杂性和内存问题。
声明一下，我喜欢 Go，也喜欢 Rust，但我认为它们面向不同市场：Go 是更好的 Python/Java，Rust 是更好的 C/C++。Rob Pike 设想 Go 是系统编程语言，但任何带 GC 的语言做系统编程都是完全不可能的。所以对作者用 Go 写工具的前提，我的看法是“为什么不”，而不是“为什么不用 Rust”；别人用 Rust 写同样工具，我也不会说“为什么不用 Go”。但有一点我不同意作者：“Go 毫无歉意地简单”。它并不像看起来那么简单，就像所有 GC 语言一样。我发现 Go 拥护者尤其对 GC 的复杂性和缺点不屑一顾，也许因为他们很多人没有多年 Java 处理这些问题的背景。我在 Google 一个团队工作过，团队用 Go 编写和维护项目（我没写过，但经验是很近的二手经验）。我记得 Go 二进制在生产中因内存限制（10GB+）爆掉，调试发现存在数百万个 Go channel 需要清理；不知为何 GC 没有清理它们，可能是非显而易见的悬挂引用，也可能不是。任何东西都可能有 bug，我的观点是 GC 是银弹只是个神话。
cletus查看英文原文
For the record, I like Go. I also like Rust. But I really see them as being aimed at different markets. Go is a better Python/Java. Rust is a better C/C++. The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language. So as for the author's pretext (writing some tool in Go), personally my view is "why not?" not "why not Rust?". If someone had written that same tool in Rust I wouldn't be saying "why not Go?". Whatever floats your boat. But here is the one part where I disagree with the author: > Go is unapologetically simple It is not as simple as it seems, just like every GC language out there. I find Go advocates in particular seem to dismissive of any GC complexities or downsides. Maybe because many of them just don't have the background in dealing with this from years of Java. I worked on a team at Google that wrote and maintained a project using Go. Note that I never wrote anything for this project so my experience was second hand but close second hand. One thing I remember was the Go binary blowing up on memory limits (10GB+) in production. Some debugging found there to be millions of Go channels (IIRC) that needed to be cleaned up. For whatever reason the GC didn't clean them up, possibly because of a non-obvious dangling reference, possibly not. Anything can have bugs obviously. It's just a myth that GC is a silver bullet is my point. There was a guy who worked on the Go team (David Crawshaw) who'd stop by every now and again. Occasionally I'd get into debates with him about Go and GC. It's from these that I established my general observations of Go pundits: 1. Full GC pauses and GC in general are totally not a problem in Go. 2. If they were, they're totally going to be fixed in Go 1.N+1 where N = the current version of Go. (At the time, the argument David made was that Go's STW GC pauses were sub-millisecond so totally not a problem).
Go 对非科班、能力混合的团队友好，上手快，比 Rust/C++ 更适合快速投入生产。
我不找工作，但常被邀请和公司开发团队聊天，能看到他们在做什么、怎么做。上一家我拜访的公司是几个物理学博士，他们在写控制软件。这个团队非常聪明，但不是高功率软件开发者：不是前内核开发者，也不在业余时间写 3D 游戏引擎，只是非常聪明、会编程的人。他们用 Go，我觉得这对他们是很棒的选择：性能足够快，开发舒服，也足够容易理解。这就是我真正喜欢 Go 的地方。Haskell 和 Common Lisp 在 HN 上很热门，但对于由非 CS 专业领域专家组成的创业公司是糟糕选择。我相信这些人能学会 Rust 甚至现代 C++，但用 Go，他们可以开始使用一种不需要一年经验才能正确使用的语言。对我许多个人小项目，我喜欢 Python；但对能力混合的团队项目，Go 似乎是好选择。
todd8查看英文原文
I'm not looking for a job, but I'm often invited to chat with a company's dev team, and I get a chance to see what they are doing and how they are doing it. The last company I visited was a handful of Physics Ph.D.s. They were writing control software. Obviously, this team was really smart, but they were not high power software developers. They weren't ex-kernel developers and they didn't write 3D game engines in their spare time. They were just really smart guys that knew how to program. They were using go, and I felt like that was a great choice for them. Fast enough performance, comfortable development, and easy enough to understand. This is what I really like about go. Languages like Haskell and Common Lisp are popular topics here on HN, but they'd be poor choices for a startup made up of domain experts that aren't CS-majors. I'm sure these guys could have learned Rust or even modern C++, but with go they could get started in a language that wouldn't take a year of experience to use correctly. For my many little personal projects, I like python, but for team projects were there will be a mix of abilities go seems like a good choice.
历次讨论
同类还值得读
开源应用架构
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编辑精选