Rust 优劣势： v.s. C++ / v.s. Go（持续更新）
Rust 发展速度比 C++ 强很多。如果去翻 open-std 的故纸堆，会发现 C++ 这边有很多人（包括标准委员会的人）提了有用的提案，但后来大多不了了之或经历了非常长的时间才进入标准。
>> C++ 设计哲学&思想体系
另外就是以前就有的：
Rust 有很漂亮的宏和植入类型系统的生命期体系。目前看来 C++ 没什么可能加进去。（虽然有的编译器已经能将生命期诊断实现为警告，但这仍与语言标准本身关系不大）
Rust 有更加简洁而规范的对象模型。 C++ 可以写出很 weird 的类型，譬如移动或 swap 抛异常的类型， Rust 就没这事。
……
我觉得你应该问就语言本身而言 Rust 比 C++ 弱在哪里。 Rust 作为站在 C++ 肩膀上发展的语言，更强是很自然的，弱的地方才需要找原因。（原因可能是在规范性上的顾虑、设计偏好等）
作者：暮无井见铃
链接：https://www.zhihu.com/question/328263899/answer/715380135
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
rust不需要人类看不懂代码也看不懂编译错误的那种黑魔法，就能实现和黑魔法一样的效果。
rust编译通过了bug比cpp少上百倍，而且因为黑魔法引发的灵异bug起码少10倍。
https://msgpack.org/msgpack.org
对比下首页里C/C++的范例代码，和Rust的范例代码，就知道什么叫黑魔法和高科技的区别了，一个直接调用只能用tuple而且还又长又臭，一个可以随便拿个struct往里面扔。
作者：诸葛不亮
链接：https://www.zhihu.com/question/328263899/answer/715307958
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
作者：孙嘉龙
链接：https://www.zhihu.com/question/328263899/answer/727826881
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
关注了很久，但上手开始转写一个现有的逻辑大概一周左右。用过很多语言，C++和Scala这种比较复杂的语言都过有过至少3年以上使用经验。说下我的使用感受，可以供准备正式入坑的人参考（不打算写实际项目的不算）
大概来泼一点冷水。
【1】上手rust之所以说曲线陡峭主要是因为，即使你看过了文档，也仍然会遇到很多问题。只不过C++是你在调试的时候遇到，rust是你在编译的时候遇到。rust的编译错误提示还算友好，但还不够友好。更多时候是设计上就不满足要求，我看了提示研究半天知道了为什么这么写不对，但不知道怎么写才能实现我要的功能。
由于生命周期约束的问题，很多其他语言的典型范式在rust上都不通用，你用过再多的语言可能也很难显著缩短学习时间。（没用过Haskell，有熟练使用Haskell来评论下？）
【2】rust的API设计首先考虑是满足rust基本原则，然后才是使用方便，而且很多地方使用方便性不足，举两个例子，大家就知道这帮人设计的标准库API易用性是个什么尿性：
- BTreeMap<f64, T>是不可用的，因为f64不是全序的（因为有NaN），语言原生类型里也没有其他浮点类型可以当作这里的key。
- map[key]=value这种赋值方式是没有的
- ———— ？？
所以rust的标准库API发展出一套自己特有的风格，跟所有主流语言都不一致。
【3】本质上来说，rust大概是给操作系统、嵌入式、业务逻辑非常复杂但又极致追求安全性的场景准备的，例如Firefox渲染引擎、TiDB这种。大部分会来看此回答的人大多不是这个群体，所以rust给你带来的好处可能远不足以抵消它过分的约束给开发效率的巨大折损。
【4】一些rust的设计模式已经出现。都说一个设计很好的语言就不需要很特别传授的设计模式，常见需求都应该能够被自然的写出来，但在我来看rust做不到这个。例如就出现了这样的：
Vec<Rc<RefCell<Box<Trait>>>>
https://www.reddit.com/r/rust/comments/33jv62/vecrcrefcellboxtrait_is_there_a_better_way/
Vec<Rc<RefCell这样的pattern已经固定，但这显然么？我觉得并不显然，只是大家的试错之后的经验，而且也没有什么糖来再封装一下。
【5】代码中充斥着语法噪音：例如什么iter()，borrow()，unwarp()，我知道这些在这里是需要的，但你跟scala对比一下，从代码视觉角度上来看这真的不能算是一个更好的C++。
看了rust之后，才知道C++标准委员会其实做的非常好了，&、&&和const等比较自然的组合在一起。虽然新人容易搞不懂，但你去看看rust，经常在lambda里面冒出一些&&&xxx，&mut &mut &xxx之类的东西，感觉就像是在看一个半成品的C++……
而且这里到底有几层哪些种&如果没有IDE的提示的时候真的不显然……有IDE提示也让人心智负担徒增。
~ 第一次新增：
【6】内存泄露不算安全问题，这个我觉得对于很多场景也有点不够，毕竟长期不重启无人值守的地方，内存泄露过快还是个挺严重的问题。
作者：Krys
链接：https://www.zhihu.com/question/328263899/answer/727800320
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
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差不多是稳赚不赔的。
原文地址：https://blog.csdn.net/chenxuanhanhao/article/details/97612996
