找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

3826

积分

0

好友

528

主题
发表于 昨天 07:20 | 查看: 7| 回复: 0

抽象几何立方体动态图

我每天使用 Rust 编程已经超过五年了。在这期间,我交付过生产环境的后端服务、命令行工具 (CLI),以及一些至今仍在运行的嵌入式系统。

当项目的核心需求是可预测的性能和零意外崩溃时,Rust 依然是我的第一选择。

但时间久了,它身上那些反复出现的问题,让最初的新鲜感和兴奋感逐渐褪去。下面要说的这几件事,至今仍会让我忍不住对着屏幕小声抱怨。

扼杀心流的编译时间

编译慢这个问题,从未真正消失。在一个包含 4 万行代码 (kLOC) 的工作空间中,哪怕只是修改一行,也可能让一台高性能机器花费 25 到 50 秒来重新编译。

虽然 Cargo 的增量编译和工作区技巧能帮上一些忙,可一旦你触碰到泛型密集的模块,或者使用了过程宏 (proc-macro) crate,漫长的等待就又开始了。

我见过不少资深工程师,在等待 cargo check 完成时,思路被硬生生打断。尽管编译器团队一直在努力优化,但在任何有实际规模的项目里,Rust 的反馈循环速度,仍然明显慢于 Go、Zig,甚至是现代的 C++。

这种因等待而被迫进行的上下文切换,其成本是真实存在的,它会持续消耗开发者的专注力。

借用检查器总是在我不想争论的问题上“赢”了我

我对所有权和借用规则了然于胸,但某些编码模式总会迫使我进行痛苦的重构。

自引用结构体 (Self-referential structs)、生命周期超过其数据源的缓存视图,或者需要在操作中转移所有权的状态机——处理这些时,总免不了一场与编译器的“斗争”。

在异步 (async) 代码中,这种痛苦还会加倍。突然间,几乎所有东西都必须是 'static + Send,否则你就得手动处理 Arc<Mutex> 或者考虑固定 (pinning) future。

我不得不承认,我写过太多 Rc<RefCell> 了,每一次都感觉像是对“优雅方案”的默默妥协。编译器是对的,但有时,这种正确性是以牺牲掉那个最直观、最直接的解决方案为代价的。

异步仍然感觉格格不入

Async/await 语法现在用起来已经顺手多了,但那个根本性的“函数颜色”问题从未消失。

一旦某个函数被标记为 async,这种“异步属性”就会像传染病一样向上蔓延。你想在异步上下文中调用同步代码,或者反过来,都需要借助一些略显笨拙的适配器。

在任务间共享数据,通常意味着必须使用 tokio::sync 家族的类型,或者套上 Arc。取消操作、select! 宏以及流处理,依然伴随着不少样板代码,而其他一些语言处理起这些问题来似乎更为简洁。

运行时 (tokio 与其他运行时) 的分裂又增加了一层认知负担:引入一个 crate 时,你总得先弄清楚,“它到底依赖哪个运行时?”

样板代码与孤儿规则税

Rust 的标准库 (standard library) 被刻意设计得很精简,所以你需要引入外部 crate 来处理日期、正则表达式 (regex)、随机数、HTTP 客户端等等常见任务。

孤儿规则 (orphan rule) 会阻止你为外部类型实现外部特征 (trait)。于是,你不得不求助于新类型 (newtype)、包装器 (wrapper) 或者各种 Deref 技巧。

最终,代码往往会变得比预想中更长:随处可见的显式 .clone().into(),用来消除歧义的 turbofish 语法 (::<>),以及动辄能滚动半页的特征约束 (trait-bound) 错误信息。

Rust 语言本身非常强大,但在日复一日的使用后,你会清晰地感受到,驾驭这种强大所需付出的“仪式感”成本。

团队速度与上手成本

即便是经验丰富的 C++、Go 或 Python 工程师,也可能在同样的生命周期 (lifetime) 或特征约束谜题上卡住好几天。

一个在其他方面都很出色的新同事,可能会因为一个借用检查错误而停滞一周——而这个错误,在你知道答案后会显得如此简单。在一个成员经验水平参差不齐的团队里,这种情况对功能交付速度的拖累,比大多数人愿意承认的要严重。

编译器是一位极其出色的老师,但同时也是一位严厉、不留情面的老师。而接受它的教导,需要付出实实在在的开发时间。


这些抱怨并非什么新发现,而且其中大部分问题,经过社区多年的努力,已经改善了许多。然而,一旦你走出玩具项目和周末实验的阶段,踏入真实的、持续迭代的生产开发,它们就成了你必须每天面对的现实。

Rust 强迫你采用的设计范式,会在系统达到一定规模时带来丰厚的回报:零数据竞争、可预测的性能,以及在许多情况下的“无畏重构”。但这一切的代价,是编译时的等待、所有权管理带来的心智负担,以及那些让你不禁感叹“怎么就非得这么绕?”的时刻。

如果你是一位正在为新服务或新团队做技术选型的中高级工程师,请务必全面、理性地看待这个问题。Rust 在安全性和性能上的优势是实实在在的,但它带来的开发阻力同样也是实实在在的,并且这种阻力并不会在你使用满一年后就神奇地消失。

对我个人而言,在大多数需要权衡性能与可靠性的场景下,我仍然会选择 Rust。但我不再假装那些粗糙的棱角已经被完全打磨光滑。它们只是变成了我已经学会如何去适应、去驾驭的一部分。

这就是来自一个五年 Rustacean 的真实感受。如果你想了解更多开发者的实战心得与行业吐槽,欢迎来云栈社区开发者广场逛逛。




上一篇:Argo CD 3.3 发布详解:PreDelete钩子、Source Hydrator增强与GitOps生命周期完善
下一篇:MWC 2026 射频技术前瞻:从U6GHz到AI赋能,解读5G-A与6G的演进路径
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-3-10 11:06 , Processed in 0.600887 second(s), 42 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表