LZ说"把空指针、数据竞争直接挡在编译期"…,这句我得较真一下。严格说,是 safe Rust 把这两类问题挡在编译期,前提是代码不进 unsafe 块。语言和标准库都留了 unsafe 逃生舱——FFI 调 C、手写底层容器、性能热路径基本绕不开。一旦进 unsafe,空指针和数据竞争的可能性又回来了,只是 responsibility 挪到了写代码的人头上。所以"直接挡住"准确的适用范围是"默认安全子集内",不是整个语言。
补一组数据比纯感受有说服力:微软 2019 年披露,他们十二年修的 CVE 里约 70% 是内存安全类漏洞,正是 Rust 想消除的那一类;谷歌同年一份 Android 研究也指出内存安全 bug 占严重漏洞的大头。这两组数字从侧面撑住了 LZ"少犯傻"的判断。但要说清边界——它们论证的是"内存安全语言整体有价值",不等于"Rust 一定比带严格 code review 的 C++ 更稳",后者目前缺对照实验,从某种角度看这个结论值得商榷。
报错那块我完全认同,compiler 当陪练这个比喻很准。不过新手前几个月被 borrow checker 卡住的成本是真实的,团队里有人会因为它编译不过就迁怒语言。严格来说护栏什么时候从保护变成门槛,得看项目阶段和团队构成,这点原文没展开。
"语言没有银弹"这句我接一句:Rust 也不是免费午餐,编译时长、二进制体积、学习曲线都是实打实的成本,小项目上未必划算。你那个"习惯带得走"的观察我很有共鸣,写回 Python 会下意识先想 None 的情况;但反过来也容易把 Rust 的严苛当标尺去嫌弃别的语言,这个心态得自己调。