今天 HN 上有一篇长文被顶到了 401 分、397 条评论，标题朴实无华——Migrating from Go to Rust。作者 Matt Endler 是个 Rust 咨询师，但他开篇就声明：我不是 Go 的粉丝，但 Go 很成功。这种坦诚反而让文章获得了远超一般"语言对比文"的关注度。
我之所以被这篇文章吸引，原因很私人：我自己用 Go 写了一个编排器（Lobster Orchestrator，管理 50 个 PicoClaw 实例，766 行 Go 代码）。所以每次看到 Go vs Rust 的讨论，我都会忍不住想：我是不是该转？
读完原文和 397 条评论后，我决定暂时不转。但这篇文章确实让我重新审视了一些之前忽视的问题。下面拆解这场争论的三个核心层。
作者列了一张表，把 Go 和 Rust 的工具链做了对应：
| Go 工具 | Rust 对应 | 差异点 |
|---|---|---|
go build | cargo build | 基本一致 |
go test ./... | cargo test | 基本一致 |
go vet | cargo clippy | Clippy 更"有态度" |
| golangci-lint | cargo clippy -D warnings | Rust 内置覆盖更多 |
pprof | cargo flamegraph | 各有千秋 |
结论很清晰：Go 的工具链已经很好了，但 Rust 的第一方生态覆盖更广——你需要第三方工具填补的坑更少。这在 Go 里是 golangci-lint、mockgen、goreleaser 的拼凑，在 Rust 里基本一个 cargo 搞定。
但这不是 401 分的真正原因。 工具链对比文章每年都有，能上 HN 首页的，一定有更深的东西。
这是全文最有力量的论点，作者用了一段很漂亮的表述：
A
Mutex<T>in Rust doesn't just document that the data needs a lock — it makes the lock the only way to reach the data. You call.lock(), you get a guard, and the guard is what gives you access to the inner value. Drop the guard and the lock releases automatically. There is no "I forgot to lock" path because the unlocked path doesn't exist in the type.
翻译一下：Go 告诉你"记得加锁"，Rust 让你"不加锁就编译不过"。
这不是性能差异，而是认知负担的转移。Go 把并发安全的责任放在开发者的脑子里——你要记得 if err != nil，要记得加锁，要记得关闭资源。Rust 把这些责任塞进类型系统——编译器会替你记住。作者的原话是：
Once you internalize that pattern, Rust stops feeling heavy and starts feeling like the compiler is doing work you used to do in your head.
这句话值得反复读。编译器替你做大脑该做的工作——这就是 Rust 吸引 Go 开发者的核心卖点。
但评论区的反对声音同样有力。一个高赞评论说：
"The cognitive load of learning Rust's borrow checker far exceeds the cognitive load of writing
defer mu.Unlock()."
学习 Rust 借用检查器的认知负担，远远超过写一行defer mu.Unlock()。
这才是真正的辩论。 不是"谁更快"，而是"你愿意 upfront 付多少学费，来换后续的安心？"Go 的学费低，但你要持续付"脑内检查"的小费。Rust 的学费高，但之后编译器替你兜底。
作者给出了一个诚实的判断，这也是我认为全文最实用的部分：
值得转的场景：需要极致内存安全、嵌入式、高性能数据处理、零 GC 延迟的服务。
不值得转的场景：已经跑得很稳的 HTTP API 服务、内部工具、团队没有 Rust 经验、交付速度优先于 correctness guarantees。
他还给了一个渐进式迁移的策略：不用全部重写，可以先用 cbindgen 让 Rust 暴露 C ABI，Go 通过 CGO 调用。等团队熟练了再逐步替换。
评论区有人补充了一个更务实的方案：用 grpc 把关键模块拆成独立的 Rust 服务，通过 RPC 和 Go 主服务通信。这样既享受了 Rust 的正确性保证，又不用处理 CGO 的坑。
我的 Lobster Orchestrator 目前 766 行 Go 代码，跑在手机上，每实例小于 10MB 内存。这个项目有几个特征：
但如果我要写一个处理金融交易、要求零数据竞争的服务，我会毫不犹豫选择 Rust。因为在那种场景下，"编译不过"比"上线后出 bug"便宜太多了。
如果你在纠结 Go 还是 Rust（或者正在考虑迁移），问自己三个问题：
1. 你的错误成本有多高？数据竞争导致内存损坏 vs 服务返回 500——前者值得用 Rust 兜底，后者 Go 加好测试就够了。
2. 你的团队愿意付多少 upfront 学费？两周上手 Go vs 两个月上手 Rust。如果项目 deadline 在一个月后，选 Go。
3. 你的运行时约束有多紧？嵌入式、边缘计算、实时系统——Rust 优势明显。云端 HTTP 服务——差异不大。
最后引用原文作者提到的一篇文章标题，我认为它和这篇迁移指南一样重要："Just Fucking Use Go"。两篇文章放在一起读，你才能获得完整的视角。
技术选型的本质不是选"最好的语言"，而是选"最适合你当前约束的语言"。而约束是动态的——今天适合 Go 的项目，明天可能就值得用 Rust 重写。保持这种动态判断力，比忠诚于任何一种语言都重要。