其实这个不是简单说哪个好，哪个不好或者说哪个不如哪个的问题，一个语言只是一个基础，它的广泛应用与成功都需要一个复杂的生态，如果要比较的话咱们来比较C++、Rust、Java和C#，Java和C#都是带GC的语言，而且这几个语言我都大量地用过。
在讨论之前先声明我也不是C++的黑，恰恰相反，我是C++的粉，在Windows、Linxu、AIX上都有大量的开发，当时做运营商的业务监控系统，要跨这么多平台，性能要压缩到极致，只能用C/C++。但是C++动不动就Core Dump真的很头痛的，因为在服务器上挂了人家不让你在服务器上进行DEBUG，而且调试也只能在控制台上调试，尤其是多线程一挂连在哪个线程挂的可能都很难定位，对这种BUG的修正需要大量时间和精力；一旦出现了野指针，程序还没挂，但数据偶尔就不对，这种情况是最难定位的。
所以，当看到Rust的内存安全，连Panic都可以把栈给打出来的时候，那种眼前一亮的感觉，就好比见到了救世主一样，写了两年Rust之后C++都不想碰，真的是回不去。内存安全是一方面，还有就是Cargo的包管理，太省事儿了。很多人吐槽Rust编译速度慢，但C++的工程大了重新编译的话速度也很慢，所以大工程一定要拆成几个工程，都得通过分代码库来解决编译慢的问题。开发Rust那帮人原来就是写C++的，为什么这么热衷于Rust，因为深受C++的折磨，想创造一种拯救系统开发程序员的新语言，我认为Rust有这种潜力，现在Rust已经被Linux的内核支持越来越好了，这就是希望。
不能简单地说C++不如Rust，在应用生态、程序员的数量上，C++是绝对绝对的优势；而Rust的各种库都还不健全、不成熟，这就影响到了Rust的普及，尤其在国内，哪个公司敢上来都用Rust，一旦有人离职，再找Rust程序就难上加难，这是个系统问题，必须要考虑的。Rust很多软件库还不成熟，一旦在生产环境使用，可能面临巨大风险。Rust也有它的缺点，它对面向对象支持不完整，以前的OOD的思想应用起来有些不顺畅，但问题不大；Rust的语法与C++差别较大，要从C/C++转过来需要一段时间来适应；unwrap的处理确实感觉很难看很难看。
再说带GC的语言，Java、C#之所以搞个虚拟机，其实就是要解决内存管理的问题，这个与Rust设计借用机制来解决内存问题是一样的，Rust的方案是在没有性能损耗的情况下的一种内存安全解决机制，而GC语言是牺牲了性能的情况下的一种解决方案。这两种解决方案也各有优缺点，带Java、C#的方案降低了门槛，初级程序员也不会犯内存管理的错误导致系统不可用，但GC还会带来性能抖动的问题，这对于时间敏感和高并发的场景也是致命的，所以现在有些大厂已经用Rust来写核心的高并发系统以解决这些问题；而Rust的入门门槛就比较高，但一旦掌握了，它的收益也非常明显。Java、C#安全让计算机来解决内存管理的问题（当然，C#也支持自己管理），而Rust选择强制让程序员自己管理好内存，只要能编译通过，基本就可以保证不再出内存问题。
总结下，C++在OOD、性能和灵活性上都做到了极致，Java、C#在内存安全、编码效率上也做到了极致，而在性能上有所牺牲；Rust在内存安全、性能、编码效率、灵活性上做了一个平衡，是最均衡的一个。
存在即合理，Java被广泛应用的企业系统的开发，足以说明了它的成功，但在高并发、高性能方面还需要借助C、Rust的辅助；C#在Windows应用开发方面占有绝对的份额，但在跨平台方面，还是C更多一些；今后在跨平台应用、系统开发、嵌入式等方面可能越来越多地见到Rust，而C可能会越来越少，但在相当相当长的时间内不会消失，或者是在很长一段时间内还将保持着其强大的江湖地位。
未来，Google如果真的解决好了与C++库互操作的问题，Rust一下就起飞了。