批判Rust语言，以及C/C++为什么永远不会死

你经常可以听到一个争论说，90%的执行时间被10%的代码所执行（据我理解，仅仅是一条经验主义 - 对一个主题快速的扫描互联网无法替代任何严格的科学的研究）。因此，你可以用安全的Rust语言写你大部分的代码，然后，剩下的10%（那些“热”代码）写在不安全的子集中，所以现有的Rust实现实际上不会有不好的性能。好的，但这不更是暗示我根本不需要Rust，因为我可以用Go写90%代码，然后用C写剩下的10%？只有那些寻找银弹的人和幻想神话的异教徒会因为所有代码都100%用同一种语言编写而感到开心，而用Rust。但实际上一种语言有两者方言，这和"Java + C"或者"Go+C"组合没什么不同。

但实际上90/10规则是垃圾话。按照它的逻辑，我们可以用Java90%重写Webkit或者VirtualBox或者GCC而得到同样的结果。但这显然是错的。并不是这个比率因不同程序而变动太大，让我们做一些计算来瞧瞧。假设整个程序用不安全的C/C++编写，并且它的执行时间，假设是0.91（一小部分热代码）+0.11（大量的冷代码）=1。现在和一个用一个带有C代码插入的安全语言编写的程序做比较： 0.91 + 0.12 = 1.1，这样，理论上说，区别是10%。是多了还是少了？这取决于项目的规模。以Google为例，即使是很少的一点比例都可以节省大量的金钱（请看第五小结，“利用”，在这篇文章中）。或者想象当下一次更新，JVM突然开始要求多10%的资源！我都害怕猜想需要多少个0在数字后面才能把比率转化为金钱。10%是C和C++完成任务所需要的所有份额。

我们不停的念咒语“不成熟的优化是所有邪恶的根源”。但如果我们想逐字的跟随，为什么在所有代码里不用冒泡排序来替换快速排序？毕竟，我们没有办法确切的知道哪里是瓶颈，对吗？为什么要把普通的活动包含在actors或者事务内存中而不用马上用更加有效率的原子？并且，通常说，在小案例中，强制性的初始化每一个单独的变量，执行一堆辅助性的检查等等根本没有意义。让你仅花额外的几分钟去考虑而获取即使只有2~5%而不是10%的性能改进，其实也不坏。此外，就像我们已经指出的，这会使C/C++程序有巨大的不同！毕竟，谁敢争辩说找到了热点，重写那些代码（也许有一堆）并且证明这真的变快了是一项比预先考虑性能而言更轻松的工作？

即使除了速度/安全问题比较之外，我还怀疑那语言的设计。特别对于它使用5种指针类型。一方面，让程序员仔细考虑他们的变量存放在栈或堆里，允不允许被多线程操作的想法并不差。另一方面，想象你在写一个程序，且在某一刻发现一些变量应该存在堆里而不是栈上。所以你用Box重写代码。接着你发现你实际上需要Rc或者Arc。另外，你重写了所有的代码。接着，再次，你再次重写它在栈上拥有普通变量。所有的东西你都手工操作而没有使用一个合适的IDE。正则表达式没有帮助。或者你刚刚结束一个噩梦像“Vec>>>” - 对Java说hello吧！但悲伤的事情是编译器已经知道每一个变量的每一件关于使用期的事，并会自动插入所有这些Box's、Arc's等等。但由于某种原因，这个责任被转移给了程序员。让程序员简单的写val（我们活在第三个千年，毕竟！）会更加方便。并且显式的在需要的地方指定特殊的Box或者Rc。从这一点看，Rust的开发人员搞砸了整件事情。这个，特别的，让Rust's的使用范围更加窄了。没有一个理智的人会用这样的一个语言写web或者服务器端软件 - 特别当考虑到它并没有提供比JVM相关语言更显著的优势。即使是Go - 带有普通轻量级的进程（不是未来) - 看起来都是一种更好的选择来解决这些任务。至于未来，你得学会如何正确的操作它们而不会砸到自己的脚 - 并且你谈到“安全”的语言，啊？确实，所有的这些语言都有他们自己的独特的怪癖 - 举“整个世界都停止了”的例子。但这个问题可以通过把代码分解成小的服务或者通过其它技术而解决。并且是的，没有人愿意把Rust转为Javascript，通过它来为AWS写脚本或则为MongoDB来做查询语言。至于安卓，它也不容易可信，但是有一个不同的理由：不仅仅只有一个架构风格，所以JVM可以做的更好。所以，如果你恰巧认为Rust是“适合所有任务”的话，我让你失望了。

还有更多的理由来终结它：

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!