<div class="htmledit_views" id="content_views"> <p> </p>html
<p>Rust 发展速度比 C++ 强不少。若是去翻 open-std 的故纸堆,会发现 C++ 这边有不少人(包括标准委员会的人)提了有用的提案,但后来大多不了了之或经历了很是长的时间才进入标准。</p>linux
<p style="text-indent:50px;"> >> C++ 设计哲学&思想体系</p>程序员
<p>另外就是之前就有的:</p>面试
<p>Rust 有很漂亮的宏和植入类型系统的生命期体系。目前看来 C++ 没什么可能加进去。(虽然有的编译器已经能将生命期诊断实现为警告,但这仍与语言标准自己关系不大)</p>chrome
<p>Rust 有<strong>更加简洁而规范的对象模型</strong>。<u> C++ 能够写出很 weird 的类型,譬如移动或 swap 抛异常的类型, Rust 就没这事</u>。</p>设计模式
<p>……</p>安全
<p>我以为你应该问就语言自己而言 Rust 比 C++ 弱在哪里。 Rust 做为站在 C++ 肩膀上发展的语言,更强是很天然的,弱的地方才须要找缘由。(缘由多是在规范性上的顾虑、设计偏好等)</p>架构
<p><br><br> 做者:暮无井见铃<br> 连接:https://www.zhihu.com/question/328263899/answer/715380135<br> 来源:知乎<br> 著做权归做者全部。商业转载请联系做者得到受权,非商业转载请注明出处。</p>函数
<p> </p>学习
<hr><p>rust不须要人类看不懂代码也看不懂编译错误的那种黑魔法,就能实现和黑魔法同样的效果。</p>
<p><strong>rust编译经过了bug比cpp少上百倍,并且由于黑魔法引起的灵异bug起码少10倍。</strong></p>
<p> </p>
<p><a href="https://link.zhihu.com/?target=https%3A//msgpack.org/" rel="nofollow" data-token="e1d908eb1aca74c03b68420384a39155">https://msgpack.org/msgpack.org</a></p>
<p> </p>
<p>对比下首页里C/C++的范例代码,和Rust的范例代码,就知道什么叫黑魔法和高科技的区别了,<strong>一个直接调用只能用tuple并且还又长又臭,一个能够随便拿个struct往里面扔</strong>。</p>
<p><br><br> 做者:诸葛不亮<br> 连接:https://www.zhihu.com/question/328263899/answer/715307958<br> 来源:知乎<br> 著做权归做者全部。商业转载请联系做者得到受权,非商业转载请注明出处。</p>
<p> </p>
<hr><p> </p>
<p>做者:孙嘉龙<br> 连接:https://www.zhihu.com/question/328263899/answer/727826881<br> 来源:知乎<br> 著做权归做者全部。商业转载请联系做者得到受权,非商业转载请注明出处。<br> </p>
<p>关注了好久,但上手开始转写一个现有的逻辑大概一周左右。用过不少语言,C++和Scala这种比较复杂的语言都过有过至少3年以上使用经验。说下个人使用感觉,能够供准备正式入坑的人参考(不打算写实际项目的不算)</p>
<p>大概来泼一点冷水。</p>
<p>【1】上手rust之因此说曲线陡峭主要是由于,即便你看过了文档,也仍然会遇到不少问题。只不过C++是你在调试的时候遇到,rust是你在编译的时候遇到。rust的编译错误提示还算友好,但还不够友好。更多时候是设计上就不知足要求,我看了提示研究半天知道了为何这么写不对,但不知道怎么写才能实现我要的功能。</p>
<p>因为生命周期约束的问题,不少其余语言的典型范式在rust上都不通用,你用过再多的语言可能也很难显著缩短学习时间。(没用过Haskell,有熟练使用Haskell来评论下?)</p>
<p>【2】rust的API设计首先考虑是知足rust基本原则,而后才是使用方便,并且不少地方使用方便性不足,举两个例子,你们就知道这帮人设计的标准库API易用性是个什么尿性:</p>
<ul><li>BTreeMap<f64, T>是不可用的,由于f64不是全序的(由于有NaN),语言原生类型里也没有其余浮点类型能够看成这里的key。</li> <li>map[key]=value这种赋值方式是没有的</li> <li>———— ??</li> </ul><p>因此rust的标准库API发展出一套本身特有的风格,跟全部主流语言都不一致。</p>
<p>【3】本质上来讲,rust大概是给<strong>操做系统、嵌入式、业务逻辑很是复杂但又极致追求安全性的场景准备</strong>的,例如Firefox渲染引擎、TiDB这种。大部分会来看此回答的人大多不是这个群体,因此rust给你带来的好处可能远不足以抵消它过度的约束给开发效率的巨大折损。</p>
<p>【4】一些rust的设计模式已经出现。都说一个设计很好的语言就不须要很特别传授的设计模式,常见需求都应该可以被天然的写出来,但在我来看rust作不到这个。例如就出现了这样的:</p>
<p>Vec<Rc<RefCell<Box<Trait>>>></p>
<p><a href="https://link.zhihu.com/?target=https%3A//www.reddit.com/r/rust/comments/33jv62/vecrcrefcellboxtrait_is_there_a_better_way/" rel="nofollow" data-token="ce4ddf211daf018e477783183eac209c">https://www.reddit.com/r/rust/comments/33jv62/vecrcrefcellboxtrait_is_there_a_better_way/</a></p>
<p>Vec<Rc<RefCell这样的pattern已经固定,但这显然么?我以为并不显然,只是你们的试错以后的经验,并且也没有什么糖来再封装一下。</p>
<p>【5】代码中充斥着语法噪音:例如什么iter(),borrow(),unwarp(),我知道这些在这里是须要的,但你跟scala对比一下,从代码视觉角度上来看这真的不能算是一个更好的C++。</p>
<p>看了rust以后,才知道C++标准委员会其实作的很是好了,&、&&和const等比较天然的组合在一块儿。虽然新人容易搞不懂,但你去看看rust,常常在lambda里面冒出一些&&&xxx,&mut &mut &xxx之类的东西,感受就像是在看一个半成品的C++……</p>
<p>并且这里到底有几层哪些种&若是没有IDE的提示的时候真的不显然……有IDE提示也让人心智负担徒增。</p>
<p>~ 第一次新增:</p>
<p>【6】内存泄露不算安全问题,这个我以为对于不少场景也有点不够,毕竟长期不重启无人值守的地方,内存泄露过快仍是个挺严重的问题。</p>
<p> </p>
<hr><p> </p>
<p>做者:Krys<br> 连接:https://www.zhihu.com/question/328263899/answer/727800320<br> 来源:知乎<br> 著做权归做者全部。商业转载请联系做者得到受权,非商业转载请注明出处。<br> </p>
<p>Rust其实强就强在,它的特性是讨好管理层的,而不是程序员,好比说“这里怎么不能这样写,好别扭,不舒服”,这些不是管理层关心的事情,管理层更关心产品质量和稳定性。你工做爽不爽是次要问题。如今就连linux内核,firefox,chrome这种项目都能有内存BUG和数据竞争,哪一个程序员要跟我说用C和C++能彻底避免这些错误,我就当他在吹牛。</p>
<p>而后管理层才是真正能够决定公司内部技术选型的人,或者你若是是下面写代码的,你要说服管理层去用一个新技术,你也要从QCD这些指标上去跟管理层谈,而不是什么你喜欢的特性。而后再加上rust和C的FFI作得不错,因此也能够逐步引入。</p>
<p>固然还有另外一个问题比较影响一个语言的长期发展,好比C++并非每一个主流编译器都像clang同样编译到LLVM IR的,而rustc只有一个编译器,而后HIR和MIR这些东西基本上成为了rust事实上的标准了。因此一旦出现向后不兼容的语法改动,rust彻底能够像2018兼容2015同样,好比这个crate是2015和那个crate是2018的能够编译到一块儿,由于只要IR层面上兼容就OK。也就是说进入稳定版之后就算发现有些地方设计得很差那也是能够改的,只要新的和老的能够一块儿编译就好了。可是我看C++好像还没提出这种相似的提案,说全部编译器都要遵循一个什么架构,之后好作新旧版本的兼容。那C++若是出现任何设计上的失误就一直背着这个历史包袱走吧。</p>
<p> </p>
<p> </p>
<p>上面基本上是比较抽象的比较,具体一点的比较的话,rust和C++里面不少东西仍是比较相似的。</p>
<p> </p>
<p>unique_ptr -> Box</p>
<p>shared_ptr -> Arc</p>
<p>span -> slice</p>
<p>RValue Reference (原对象每每保存一个空状态) -> move semantics</p>
<p>C++在网上也有一个很不成熟的lifetime checker的实现(基于clang),可是连一个函数返回一个抓了引用的lambda都检测不出来。visual studio貌似也有一个,不过我没用过,不评论了。</p>
<p> </p>
<p> </p>
<p>唉,其实说了那么多,最直观的感觉就是,假如团队里面来了一个Junior Engineer,若是是rust的模块,我敢让他写代码,只要他的代码里没有unsafe基本上我不太担忧,最多屁颠屁颠跑过来问“哎呀,为何这里编译不过”,要是C++的话真心不敢放手让他写,到时候不知道会给其余人挖多大个坑。</p>
<p> </p>
<p>====================20190701修改=========================</p>
<p>评论区有人提出rust对tech leader也是有帮助的,这点我很赞成。</p>
<p>leader和member这两种角色有很大的不一样,member通常就是在一家公司呆两三年就跑路了,后面这个项目怎么样其实根本管不着。每每leader在公司呆的时间长些,因此一个项目后期好很差维护,leader们比较关心。上面说的是通常的状况。因此若是有决定权的人喜欢rust,对rust的生态发展是有好处的。</p>
<p> </p>
<p>而后根据我最近面试一些C++候选人的状况,基本上C++程序员对C++11以及以上的不少东西都不清楚。因此说不管项目是采用rust仍是现代C++都是要学习成本的,并非说只有rust才有学习成本。</p>
<p>通常技术选型的时候,使用新技术就是看前期学习成本的投资能不能在后期赚回来。若是和C++98相比,那绝对能赚回来由于rust比C++98好太多,若是和现代C++相比,反正你们都有学习成本(现代C++的学习成本可能稍微低点,可是好不到哪去),虽然现代C++在一些方面好上一些,可是仍是有差距。有时候无非就是一些第三方库是C++的因此那些模块就用C++,否则如今引入rust差很少是稳赚不赔的。</p>
<p> </p>
<hr><p>原文地址:https://blog.csdn.net/chenxuanhanhao/article/details/97612996</p> </div>