提问

AI 银弹

团队来了一个经验丰富的新人，在入职的第三天，团队负责人沟通说，在新人的建议下，考虑把系统的 Go 服务逐步迁移到 Rust，并先在新系统的某个模块开始使用。我抛了两个问题，收益是什么？代价呢？

一遍遍强调耳熟能详的，Rust 相比于 Go 有很大的性能提升，没有 GC 带来的长尾耗时优化；相比于 C++ 有更好的内存安全保障。

但是代价呢，就说有没有优势就完了？

就引入 Rust 来说，有他的一体两面。现实是，Rust 语言本身的生态完善度、团队的知识储备、和现有架构的契合程度，这些不是考虑的因素吗？现在已经有了基于 Go 和 C++ 比较完善的基础架构和丰富的经验，引入 Rust 之后，短时间内又难以完整替换 Go 或 C++，同时维护三套技术体系及基础架构的复杂度不应该考虑下吗，尤其是在一个生死未知的 “创业团队”？

另外，算上新人满打满算 4 个研发，接管原本一百多号人维护的完整在线程序化广告交易引擎。

AI 太强大了，有了 AI，一切问题都迎刃而解，是这样的吗？只能期望是吧，我知道，会引入，自己也改变不了。

你怎么看？

注: 以下全文由 ChatGPT 生成

ChatGPT 回答

我其实比较认同你提的两个问题：

收益是什么？

代价是什么？

可惜很多技术讨论，尤其是 Rust、AI 这些热门话题，很容易只讨论前者，而忽略后者。

Rust 是不是好？

当然好。

我自己也认为 Rust 是目前工程设计最优秀的系统语言之一。

它解决了很多 C/C++ 十几二十年没有真正解决的问题：

• 内存安全

• 数据竞争

• 零成本抽象

• 没有 GC

• 性能非常优秀

• 编译器帮助发现大量 Bug

这些都是真的。

但是……

语言优秀 ≠ 项目适合。

这是两个完全不同的问题。

技术选型应该看 ROI，而不是语言排行榜

一个成熟团队讨论技术选型，一般都会看四件事情：

收益（Benefit）

成本（Cost）

风险（Risk）

机会成本（Opportunity Cost）

很多人只会说第一条。

例如：

Rust 快。

然后结束。

这不是技术方案，这是宣传语。

你的团队情况，我看到几个关键词

创业团队

四个研发

接管一百多人的广告引擎

这三个关键词组合起来，我第一反应不是：

Rust 能提升性能。

而是：

你们最大的瓶颈真的是 CPU 吗？

程序化广告（RTB）这种系统，我反而更关心：

• 有没有 SLA

• 有没有稳定上线流程

• 有没有完善监控

• 有没有压测体系

• 有没有自动回滚

• 有没有值班体系

• 有没有知识沉淀

• 有没有自动化测试

因为这些东西，远比：

Go 比 Rust 慢 10%

重要得多。

Go 最大的优势，其实不是 GC

很多人理解 Go：

GC。

Goroutine。

其实不是。

Go 真正厉害的是：

工程效率。

例如：

新人一周能开始写代码。

半年以后基本没人写出特别奇怪的 Go。

一年以后团队代码风格高度一致。

这是 Go 最恐怖的地方。

而 Rust 呢？

一个优秀 Rust 工程师：

可能写得非常漂亮。

另一个普通 Rust 工程师：

可能 lifetime 写到怀疑人生。

最后：

整个团队只有两个人敢改核心代码。

这就是维护成本。

Rust 的成本，很多人不会告诉你

例如：

① 培训成本

不是：

学一下语法。

而是：

真正理解：

Ownership

Borrow Checker

Lifetime

Unsafe

Pin

Async

Tokio

Send / Sync

Interior Mutability

这些没有半年以上，很难说熟练。

② 招人成本

Go：

市场非常成熟。

Rust：

优秀 Rust 工程师少得多。

尤其真正写过大型后台系统的人。

③ 基础设施成本

你们现在已经有：

Go

C++

CI/CD

监控

日志

Profiling

RPC

部署

运维

全部围绕 Go。

现在引入 Rust：

意味着：

CI 要支持。

静态扫描要支持。

安全扫描要支持。

镜像要支持。

Debug 要支持。

Crash Dump 要支持。

Profiling 要支持。

依赖管理要支持。

开发机环境要支持。

新人文档要支持。

……

这些不是一天完成的。

④ 三语言维护

这是我最担心的。

现在：

Go

C++

以后：

Go

Rust

C++

三套：

Build

依赖

工具链

最佳实践

代码规范

招聘

Review

全部三份。

四个人维护。

你觉得压力会不会变大？

AI 能不能解决？

这是最近最流行的一句话：

AI 都能写。

我觉得：

AI 确实能降低语言门槛。

但是：

降低的是：

写出来。

不是：

维护十年。

举个例子。

AI 可以生成：

2000 行 Rust。

但是：

凌晨两点：

线上：

一个 Tokio Runtime Deadlock。

一个 unsafe。

一个 Arc<RwLock<HashMap<...>>>。

一个 Future 没有 Send。

AI 能不能第一时间定位？

当然可能帮助你。

但是：

最后背锅的人是谁？

还是值班的人。

AI 最大的问题不是写代码

而是：

谁判断 AI 写的是对的？

Rust 尤其如此。

Rust 很容易：

AI 为了让 Borrow Checker 通过。

疯狂 clone。

疯狂 Arc。

疯狂 Mutex。

最后：

代码能编译。

性能下降。

设计变差。

维护更难。

如果团队没人真正懂 Rust。

Review 根本 Review 不出来。

创业团队最大的资源是什么？

不是 CPU。

不是内存。

是：

时间。

每个月：

只有那么多人天。

如果花：

三个月：

把 Go 改 Rust。

那这三个月：

没有新功能。

没有客户需求。

没有稳定性建设。

没有监控。

没有报警。

没有自动化。

这就是：

机会成本。

我反而赞同一种更保守的做法

如果真的要引入 Rust。

那应该满足几个条件。

例如：

Go 明显已经成为瓶颈。

例如：

CPU 占 90%。

GC 占 20%。

Profiling 已经证明：

Rust 可以明显改善。

再：

只替换最适合的模块。

例如：

• 高性能 Codec

• 压缩

• 加密

• JSON Parser

• 特殊计算

• SIMD

• 状态机

这些都可以：

Rust Library

↓

CGO

↓

Go 调用。

而不是：

"整个服务以后都 Rust。"

这是两个完全不同的战略。

最后，说一个我比较在意的细节

你提到：

新人第三天。

我觉得真正让我担心的，不是 Rust。

而是：

团队决策机制。

一个新人可以提出建议，这很好。

但是：

如果一个影响未来数年的技术路线，仅凭入职三天的建议就开始决定，那说明团队需要更严谨的技术决策流程。

成熟的工程团队通常会要求：

• 明确当前痛点（有什么证据证明现状存在问题？）

• 给出可量化的收益（预计提升多少？如何验证？）

• 分析引入成本（学习、招聘、基础设施、维护）

• 分析风险（是否可回退？是否影响交付？）

• 做一个小规模 PoC，通过数据验证，而不是凭印象决策

• 再决定是否推广

这样，无论最终结论是 Go、Rust，还是其他技术，都是基于工程事实，而不是技术热度。

所以，如果问我的结论，我不会说「不要用 Rust」，也不会说「Rust 一定值得」。

我的结论是：

对于一个只有 4 名研发、需要接管一个原本由百余人维护的广告交易系统的创业团队来说，最大的风险通常不是 Go 的 GC，而是团队交付能力、系统可维护性和组织承载能力。

Rust 是一种优秀的工具，但引入它本身就是一项工程投资。只有当它解决的是当前最主要、最昂贵的问题，并且收益能够覆盖学习、维护和组织成本时，这项投资才是合理的。否则，它很可能会成为新的复杂度来源，而不是银弹。

至于 AI，我认为它最大的价值是提高已有能力的产出效率，而不是替代工程判断。AI 能帮助一个熟悉 Go 的工程师更快写 Go，也能帮助一个熟悉 Rust 的工程师更快写 Rust；但它并不能替团队承担技术债、维护成本和长期架构演进的责任。这些最终仍然需要团队自己做出并承担决策。