Rust其实强就强在，它的特性是讨好管理层的，而不是程序员，比如说“这里怎么不能这样写，好别扭，不舒服”，这些不是管理层关心的事情，管理层更关心产品质量和稳定性。你工作爽不爽是次要问题。现在就连linux内核，firefox，chrome这种项目都能有内存BUG和数据竞争，哪个程序员要跟我说用C和C++能完全避免这些错误，我就当他在吹牛。
然后管理层才是真正可以决定公司内部技术选型的人，或者你如果是下面写代码的，你要说服管理层去用一个新技术，你也要从QCD这些指标上去跟管理层谈，而不是什么你喜欢的特性。然后再加上rust和C的FFI做得不错，所以也可以逐步引入。
当然还有另一个问题比较影响一个语言的长期发展，比如C++并不是每个主流编译器都像clang一样编译到LLVM IR的，而rustc只有一个编译器，然后HIR和MIR这些东西基本上成为了rust事实上的标准了。所以一旦出现向后不兼容的语法改动，rust完全可以像2018兼容2015一样，比如这个crate是2015和那个crate是2018的可以编译到一起，因为只要IR层面上兼容就OK。也就是说进入稳定版以后就算发现有些地方设计得不好那也是可以改的，只要新的和老的可以一起编译就行了。但是我看C++好像还没提出这种类似的提案，说所有编译器都要遵循一个什么架构，以后好做新旧版本的兼容。那C++如果出现任何设计上的失误就一直背着这个历史包袱走吧。
上面基本上是比较抽象的比较，具体一点的比较的话，rust和C++里面很多东西还是比较类似的。
unique_ptr -> Box
shared_ptr -> Arc
span -> slice
RValue Reference (原对象往往保存一个空状态) -> move semantics
C++在网上也有一个很不成熟的lifetime checker的实现（基于clang），但是连一个函数返回一个抓了引用的lambda都检测不出来。visual studio貌似也有一个，不过我没用过，不评论了。
唉，其实说了那么多，最直观的感受就是，假如团队里面来了一个Junior Engineer，如果是rust的模块，我敢让他写代码，只要他的代码里没有unsafe基本上我不太担心，最多屁颠屁颠跑过来问“哎呀，为什么这里编译不过”，要是C++的话真心不敢放手让他写，到时候不知道会给其他人挖多大个坑。
====================20190701修改=========================
评论区有人提出rust对tech leader也是有帮助的，这点我很同意。
leader和member这两种角色有很大的不同，member一般就是在一家公司呆两三年就跑路了，后面这个项目怎么样其实根本管不着。往往leader在公司呆的时间长些，所以一个项目后期好不好维护，leader们比较关心。上面说的是一般的情况。所以如果有决定权的人喜欢rust，对rust的生态发展是有好处的。
然后根据我最近面试一些C++候选人的情况，基本上C++程序员对C++11以及以上的很多东西都不清楚。所以说无论项目是采用rust还是现代C++都是要学习成本的，并不是说只有rust才有学习成本。
一般技术选型的时候，使用新技术就是看前期学习成本的投资能不能在后期赚回来。如果和C++98相比，那绝对能赚回来因为rust比C++98好太多，如果和现代C++相比，反正大家都有学习成本（现代C++的学习成本可能稍微低点，但是好不到哪去），虽然现代C++在一些方面好上一些，但是还是有差距。有时候无非就是一些第三方库是C++的所以那些模块就用C++，不然现在引入rust差不多是稳赚不赔的。
