2026 年 6 月，Tony Bai 在博客《在 AI 编码时代，为什么我们依然选择 Go 而不是 Rust？》里提到一个有意思的变化：Cursor、Claude Code、Copilot 这类工具，已经能帮开发者写出可以通过编译的 Rust 代码。
这件事放在几年前很难想象。Rust 最让人头疼的地方，恰恰是生命周期、借用检查器、Traits 这些概念。很多人不是不认可 Rust 的安全性和性能，而是还没等到项目落地，就先被学习曲线劝退了。
AI Coding 把这道门槛削低了。它能生成样板代码，解释编译器报错，协助改类型和生命周期。开发者不必从第一天开始就和每一个复杂类型死磕。
但 Tony Bai 那篇文章的重点并不是“Go 要被 Rust 替代”。他真正提醒的是：AI 能帮人写出代码，不代表团队就能轻松维护代码。线上系统看的是项目规模、团队经验、交付节奏，还有出故障后的代价。
放到 AI 基础设施里，这个问题更具体。训练、实验、论文复现仍然离不开 Python，框架和使用习惯都在那里。可一旦走到推理服务、网关、索引器、存储引擎、长期在线的 Agent 运行环境，问题就不只是“写得快不快”。服务要持续跑，要扛并发，要处理复杂内存状态，还要尽量少出现那种排查半天才知道根因的崩溃。
AI 把 Rust 最硬的门槛磨低了
Rust 过去难推广，一个原因很直接：它要求开发者在编译期把很多事想清楚。所有权怎么转移，引用能活多久，哪些类型能跨线程安全使用，这些都要写进代码和类型系统里。
这套机制能挡住不少内存错误，也会挡住不少新手的耐心。
ReversingLabs 在《How AI coding is breathing new life into Rust》中提到，Rust 多年来积累的安全性、性能和可靠性，正在和 AI 编程工具结合，带来新的使用场景。这个说法并不夸张。变化不在于 Rust 忽然变简单了，而在于 AI 工具替开发者分担了一部分和编译器来回拉扯的成本。
这对基础设施团队很关键。
过去做底层组件，团队常在 C++、Go、Python 之间取舍：C++ 性能强，但内存风险高；Python 写起来快，却不适合承担所有高并发底层组件；Go 简洁，并发模型成熟，工程落地顺手。Rust 常常卡在一句话上：好是好，团队写不动。
现在这句话没那么绝对了。AI Coding 至少让一部分原本被 Rust 语法和类型系统挡在门外的开发者，有机会更快进入可工作的状态。
基础设施怕的不是慢一点，是随机炸
Rust 被重新讨论，并不只是因为性能。
在长期在线服务里，速度当然重要，但更麻烦的是运行时不确定性。空指针、数据竞争、缓冲区越界、内存泄漏，任何一个问题都可能从代码层一路拖到运维层。尤其是推理服务、缓存、检索、存储这类组件，出问题时往往不是重启一下就结束。
Rust 的价值在于，它把一部分错误提前到了编译期。所有权机制、借用检查、类型系统，会强迫开发者在上线前处理掉不少内存安全问题。写的时候更费劲，换来的是线上少一些随机崩溃。
知乎专栏《Rust正在成为AI Coding的新王》提到，随着 AI 生成代码进入企业核心系统，内存安全漏洞的代价会变高，美国政府也开始推动内存安全语言在关键基础设施中的使用。这个判断不能直接推导出“所有团队都会改用 Rust”，但它说明了一个变化：代码生成越来越便宜之后，代码运行时的安全边界反而更值钱。
AI 生成代码还有一个副作用：代码量更容易膨胀。
过去开发者可能因为嫌麻烦少写几层抽象。现在工具可以很快生成一批服务、接口、适配层。代码越多，审查越难，隐藏问题越多。Rust 的编译期约束像一道硬门槛，不舒服，但能挡住一批低级错误。
Go 仍然是很多团队的稳妥选择
讨论 Rust 时，很容易把 Go 写成“旧选择”。这不准确。
Tony Bai 那篇文章之所以值得看，正是因为它没有把 AI Coding 时代的语言选择讲成一场替代赛。Go 的优势仍然清楚：语法简单，编译快，部署方便，并发模型好理解，团队协作成本低。
大量 I/O 密集型服务、控制面服务、内部平台、业务网关，用 Go 依然合适。很多团队需要的不是更强的类型系统，而是可预期的交付节奏，以及新成员能尽快读懂代码。
Rust 更适合放在风险更集中的地方：推理服务里的高性能组件，向量数据库的存储和索引层，对延迟敏感的网关，需要精细控制内存的边缘或端侧模块。
Databend Labs 在 QCon 北京站分享《Rust：构建新时代基础设施的首选语言》时，也是在云原生数据库这类基础设施语境下讨论 Rust。那次 QCon 北京站包含向量数据库、云原生、异构计算、面向 AI 的存储、微服务架构治理、FinOps 等近 30 个专题。Rust 出现在这样的场合，说明它已经不只是语言圈内部的话题，而是被放进真实系统建设里衡量。
更接近现实的判断是：Go 会继续承担大量工程服务，Rust 会进入更多关键链路。两者不是简单的替代关系。
Python 不会消失，底层会分得更细
Python 在 AI 领域的地位短期内很难动摇。研究、训练、数据处理、模型调用，仍然离不开它。CSDN 相关文章提到，PyTorch 在深度学习研究中占据很强位置，这也解释了为什么 AI 开发者很难离开 Python。
但 AI 基础设施本来就不可能只靠一种语言。
训练脚本、推理引擎、调度系统、存储系统、网关、可观测性组件，各自面对的约束不同。Python 负责高层表达，C++、CUDA、Rust、Go 负责底层执行和服务化，这种分工会越来越常见。
也要看到 Rust 的限制。CSDN 那篇文章提到，原生 Rust 二进制文件在 Serverless 架构下可能存在适配问题。这个提醒很实际：Rust 不是万能答案。部署环境、冷启动、依赖管理、团队调试经验，都会影响最终效果。
基础设施选型最怕把语言当信仰。Rust 也一样。
Rust 的位置，会先从高风险模块打开
AI 基础设施现在真正需要的，不是又一种看起来先进的语言，而是能长期稳定运行的组件。
推理请求会持续进入线上系统，Agent 会保持更长时间的状态，向量检索和缓存会成为更多应用的底座。只要这些组件进入生产环境，内存安全、并发安全、可预测延迟就会变成实际成本。
Rust 重新受到关注，原因并不复杂：AI Coding 降低了它的编写阻力，AI 基础设施又提高了对稳定性的要求。两件事碰到一起，Rust 的位置自然往前挪。
这不等于所有团队都该立刻改写技术栈。更实际的做法是，把 Rust 用在崩溃代价高、内存风险高、性能边界清楚的模块里；把 Go 留给更需要快速交付和团队协同的服务；把 Python 留在模型开发和高层编排中。
AI Coding 让写代码变容易了，也让另一个问题更突出：这些代码能不能长期可靠地跑下去。Rust 的机会，就在这道缝里。
