工具更加好用
优化策略更激进， 理论上比 C 性能高

缺点是因为它优化更激进， 因此更容易写错， 进而它更保守， 强迫你考虑清楚， 因此写 rust 比写 C 心智负担更重， 我觉得这还不像宣传的那样， 等你习惯了就好了， 而是无论哪个阶段， 感觉都比写C要费劲， 不过调试负担， 改 bug 负担会轻。

一方面这确实可以帮你检查出更多在 C 中根本没意识到的问题；
另一方面， 理论上有， 但实际上不会出现的问题 C 中可能你就根本不会意识到， C 编译器也不 care, 因此你很高兴的认为工作结束了; 它却揪着不放， 必须让你改了， 这就让人很烦。 更烦的是， 它的规则往往过于保守，带有附加伤害， 而且本质上其实不自洽:

unsafe要求程序员保证没有 Bug, 换句话说就是， 我能检查出来的， 就放在 safe code, 强迫你不出问题， 检查不出来的， 就要求你放在 unsafe, 然后你保证没 bug; 所以总体上我没有 bug, 若有， 就是你违反了 unsafe 不出 bug 的承诺。。。 这导致了， unsafe 要求带 #Safety 注释， 说明你怎么用才不会出问题， 若不按注释来， 出了问题是你使用者不按说明， 不是我错了。


最后， 它的规则很多还没有确定， 也解释不清到底是有问题还是没有； 容易吵架， 一帮人认为有， 一帮人认为没有， 吵翻天， 最后还没达不成一致。

不过总体上， 还是C 之后的一次有创意的大胆尝试， 这帮人真的是在做老黄牛，人肉穷举编程中所有安全的不安全的因素， 想方设法的给不安全的写法填堵， 极力的给安全的写法增加方便， 以减轻填堵的措施的附加伤害。 --- 所谓苦了我一代， 幸福千万代。

这种人肉苦力的一个表现就是它独特的 stabilized API 演进过程， 我自己理解者就是写了一个 API, 然后根本考虑不清楚所有可能， 因此不敢直接放出来， 这帮人拼命想各种 case, 看是否会导致这个 API 出现问题， 只有想清楚了， 自己放心了， 这才 stabilize， 进入正式版。

rust 工具链之所以好用， 我觉得就是他们将这个劲头放在了工具链功能设计上， 因此功能那叫一个好用， 那叫一个贴心。


【 在 wjhtingerx 的大作中提到: 】
: 主要特性是啥，解决了哪些问题？
--
修改:zylthinking2 FROM 220.181.41.*
FROM 220.181.41.*