写了快十年代码，C和C++里熬过的夜不提也罢。后来碰上Rust，头一回觉得编译器能当队友而不是拦路虎。

它最戳我的是所有权和借用检查。悬垂指针、数据竞争这种最容易埋雷的东西，编译期就直接卡死，连跑都不让跑。刚开始被borrow checker怼得怀疑人生，改不动时真想砸键盘。可熬过去再看，那些被它拦下来的，恰恰是我以前在C里要debug到天亮的坑。

没GC却内存安全这点也很对我胃口，zero-cost abstraction让性能和可读性不用二选一。嗯cargo一把梭把构建依赖管得服服帖帖，报错信息还特别实在。门槛看着高，其实是逼你把设计先想清楚再动手，反倒治好了我随手就写的坏毛病。

现在新项目能上Rust的都尽量上，踏实。

关于"门槛高其实是逼你把设计想清楚"这点，我倒觉得没那么绝对。borrow checker 拦下来的坑确实有一部分暴露了设计缺陷，可也有相当比例是所有权模型跟人的直觉在打架，跟设计清不清楚没必然关系——很多在 C++ 里写得毫无破绽的逻辑，到 Rust 这儿得套好几层 Rc/RefCell 才过得了编译。这更像是一种思维范式的切换成本，未必都等于"设计更清楚"了。

关于"没GC却内存安全"这句，严格讲Rust靠的是编译期静态检查换来这个保证。unsafe块和FFI那部分还是得自己把关，borrow checker也管不到运行时的借用。

补充一点：内存安全只在 safe Rust 里才保证，unsafe 块里那些雷照样埋得下。

zero-cost abstraction容易被理解成"抽象都免费"，它本意是"不为没用到的抽象付代价"。像dyn trait、Rc这类运行期还是有开销，只是你用了才付。

你被borrow checker怼到想砸键盘那段，我看着直点头。我年轻那时候用的机器还得自己管memory，漏一个pointer，半夜就给你罢工。后来有了GC…，省心归省心，可真撞上诡异的bug反而没处下手。话说回来

Rust这套，说白了是把麻烦挪到动笔之前。你说的"门槛高其实是逼你想清楚"，这句我挺有共鸣。年轻时候总想着先run起来再说，回头收拾烂摊子才知道疼。现在能忍住不乱写，倒像是被工具把坏毛病扳回来了。

不过也别把它当神，坑换个样子还在那儿。你现在新项目都梭哈Rust了？胆子比我大 (^^)

顺带较个真，"没GC却内存安全"这句得补个限定。Rust 保证的是 memory safety，但内存泄漏（leak）不在承诺范围内，标准库文档白纸黑字写了不保证无 leak。比如 Rc 循环引用一下，引用计数归不了零，那块内存就一直挂着。所以准确说是防住了一大票最坑的 bug，不是字面意义上的绝对安全。

data race 和 race condition 也得分开看。borrow checker 在编译期卡死的是 data race，逻辑层面的竞争条件它管不了，那种坑还是得自己 design 清楚。

不过楼主说"逼你把设计先想明白再动手"这点我挺认同，ownership 这套心智模型建起来之后，确实治好了随手就写的毛病。

楼主被borrow checker怼到想砸键盘那句太有画面了 我刚上手那会儿也天天和它较劲 改不动真能憋一肚子火
哈哈
熬过来确实香 现在写别的语言反而老担心哪儿埋了雷 这玩意儿把人惯坏了都

听你这么聊，倒觉得那个borrow checker像个性子硬的损友，平时怼得你没脾气，其实把你最容易栽的跟头都提前挡住了。看你如今写新项目这么踏实，真替你开心 ^_^

被borrow checker拦下的那个晚上，倒不觉得恼了。那些红线像缰绳，不是捆你，是怕你坠进自己挖的坑。

借你帖子里"数据竞争"那个说法多补一句。Rust在编译期真正能卡死的，是data race，也就是内存安全意义上的数据竞争，靠Send和Sync那套规则在编译期就拦下来。但更广义的race condition，比如典型的"检查再设置"那种逻辑竞态，borrow checker其实管不到，跑起来照样出乱子。

从某种角度看，它逼你想清楚的，主要还停留在"这块内存在哪个时刻归谁所有"这一层，并没有把并发设计的所有坑都替你填平。你最后那句"治好了随手就写的坏毛病"，我倒觉得比"内存安全"更站得住，它是真的在改你写代码的习惯，而不只是改你写出来的代码。

你那几个新项目里，有没有哪回是borrow checker怎么都过不去、最后发现是并发模型没想明白的？挺想听听这种case。