为什么 Rust 这么火，但很多公司还是主用 Go 和 Java？

如果项目不是为了追求极致的吞吐、超低的延迟或者在内存极度受限的物理环境下运行，企业几乎没有理由放弃 Go 或 Java 去转投 Rust。

学习曲线陡峭与高昂的开发成本

Rust 通过所有权、借用检查器、生命周期等机制，在编译期消除了内存安全隐患，并且不需要垃圾回收。

但在日常业务开发中，这种极致安全的代价，是极高昂的心智负担和交付周期成本：

与编译器斗智斗勇的开发成本，虽然业务逻辑本身并不复杂，但整体开发周期却被拉长了近 3 倍。在 Go 语言中，新手开发人员一天就能开发出几个接口并调通；而在 Rust 中，开发人员的大部分时间都在处理诸如生命周期标注、多线程下所有权的转移等编译问题。

冷启动与招聘成本，Go 的设计哲学是极简，一个具备 Java 背景的开发人员，通常在一两周内就可以开始编写生产级的 Go 代码。而 Rust 的语法和概念极其复杂，心智负担极重。我们当时在招聘市场上招一个具备 2 年以上 Rust 实战经验的工程师，收到的简历寥寥无几，最后只能靠组内老员工带薪学习。这种前期的人才培养周期和招聘溢价，是大部分快速迭代业务的团队难以承受的。

Go 与 Java 生态壁垒

在日常的业务开发中，编程语言本身的性能不是决定性的，生态环境才是。

Java 的生态，Java 拥有以 Spring 为核心的庞大生态圈。从各种中间件的官方 SDK、成熟的数据库驱动，到完善的监控体系（如 SkyWalking 等 APM 工具和 JVM 调优诊断工具），Java 生态基本可以开箱即用解决几乎所有的企业级问题。如果改用 Rust 编写同样的微服务，为了对接公司内部一些老旧的自研中间件，可能需要自己从零手写 Rust 的客户端和连接池，这在商业决策上基本不可接受。

Go 在云原生生态的统治力，已经成为了现代云原生基础设施的开发首选。从 Docker、Kubernetes，到 Prometheus、etcd，整个云原生生态体系几乎都是用 Go 构建的。选择 Go 开发微服务，可以无缝对接这些成熟的云原生组件，运维和二次开发的工程链路极其简单。

而 Rust 社区，虽然有 Tokio、Axum 等不错的库，但整体的微服务生态相比 Java 和 Go 仍然较为零碎。

内存安全与 GC 性能的边际效应递减

Rust 的最大技术优势是无 GC 情况下保证内存安全，但大多数企业级 Web 后端，比如常规的 CRUD 业务、API 网关，这个优势带来的边际效应递减非常严重。

业务瓶颈不在 CPU，常规 Web 业务的性能瓶颈通常存在于数据库 I/O、网络传输或分布式缓存的读取，而不是 CPU 计算或 GC 垃圾回收。

GC 停顿已被钝化，Java 和 Go 的垃圾回收技术已经非常成熟。Java 的 ZGC 和 Go 的三色标记垃圾回收器已经能够将 STW 停顿控制在毫秒级，Go 甚至能够控制在微秒级。为了解决一个对用户体验和系统吞吐几乎毫无影响的 GC 停顿，而牺牲数倍的开发效率和招人成本，绝大多数商业项目都觉得不值当。

Rust 适合的场景

根据我们的实践经验，Rust 适合的并不是常规的业务逻辑开发，而是性能要求极致、且对资源消耗极其敏感的系统级场景：

1. 基础架构与底层内核：例如分布式数据库的存储引擎（如 TiKV、Databend）、网络代理（如 Linkerd）、服务网格等底层核心组件。

2. 前端工具链重构：近年前端工具链好多用了 Rust 重构。例如 swc、rspack。我们把项目里的 webpack 换成 rspack 后，冷启动时间从 1 分钟缩短到了 5 秒，这才是 Rust 优势的正确释放方式。

3. WebAssembly 与边缘计算：在内存和 CPU 受限，且需要快速冷启动的边缘设备或 Serverless 场景中，无 GC、极小内存占用的 Rust 优势非常明显。

未来五年：Rust 能否取代 Go 或 C++ 的部分生态位？

1. 能否取代 Go？

在未来五年内，Rust 很难在常规微服务和网络服务领域动摇 Go 的地位。Go 简单、易维护、天然契合容器化和云原生生态的定位，决定了它仍然是大多数企业应用开发的首选。尽管 Rust 在工具链开发上替代了部分 Go 的份额，但在主流业务开发维度，两者并不会发生大规模的生态位替换。

2. 能否取代 C++？

在未来五年内，Rust 将会加速蚕食 C++ 的新建项目市场。C++ 的历史包袱过重，内存管理完全依赖开发者的心智，且缺乏现代化的包管理工具。目前在系统级编程（如新型中间件、操作系统安全组件、虚拟化技术）的绿地项目（新建项目）立项时，Rust 已经成为首选。

然而，对于像游戏引擎、音视频编解码、科学计算等拥有庞大 C++ 存量遗留代码的领域，重构成本是天方夜谭。Rust 的替代过程将是一个以十年为单位的漫长过程。

一些容易踩的坑

最后，根据我们团队的实际踩坑经历，给考虑引入 Rust 的团队提几个具体的建议：

1. 别在常规 CRUD 业务上死磕 Rust。没有复杂的 CPU 计算、没有极致的低延迟要求，纯粹的 I/O 交互用 Rust 写不仅体现不出性能优势，反而会被各种类型转换和所有权限制折磨得体无完肤。
2. 不要低估团队的技术转型阻力。如果团队成员没有系统级编程经验（如指针、内存模型），强推 Rust 会让开发进度停滞，甚至引发团队成员的焦虑和抵触。
3. 要做好自己造轮子的准备。现阶段很多企业级中间件和私有云系统的 Rust SDK 支持很不完善，立项前必须花时间评估对接现有系统的兼容性，否则开发到一半会发现路走不通。

选择语言不是选择最先进的，而是选择最适合商业现实的。Go 和 Java 凭借开箱即用的开发效率和强大的企业级生态，依然是商业应用开发中最务实的选择。