@RobberPhex 这也是我觉得 rust 优于 c++的原因，在写 c++的时候我需要花费大量精力去检查是否有 UB 等算是附属性困难的问题。而 rust 中，在 unsafe 以外我就完全不需要考虑这些，只要让编译器通过即可，甚至可以差不多像托管语言一样编程，称之为解放感也不足为过。

@RobberPhex 我觉得你这结论不对。开发中处理本质性的困难就已经很麻烦了，可是如果编程语言 /工具又增加了附属性的困难，那不是难上加难。这也是为什么有的语言可能开发效率高，有的语言可能开发效率低。

@mingl0280 请问敢说自己精通 c++？

@newmlp 注意看，我说的是有 gc 的语言不会内存泄露，而没有说 rust 不会内存泄露。

@3dwelcome 你的意思是，没有不好用的语言，只有写 bug 的人呗。但是前半句话就不成立，不然同样是底层高性能，为什么不用 C ？
C++的问题不是有 UB，而是你用正常的代码写着写着，不知道什么时候就 UB 了，这才是 C++恶心的地方。而其他语言易用之处也就在于此，就是正常的代码的行为都是“符合预期”的，要用指针等危险代码就要用特殊语句。
就比如你说的那个 memcpy overlap 的问题，rust 里，专门把 memcpy 拆成了 std::ptr::copy 和 std::ptr::copy_nonoverlapping 。就相当于跟你说清楚，有可能 overlap 的情况用这种，你能保证不可能 overlap 的情况用这种。

@3dwelcome 我主要想说的是，内存安全漏洞占所有漏洞的比例一直是很高的，这反应的是 c++现有的范式及辅助工具等，并不能防止这些错误，而不是说 c++漏洞多。所有语言都能写出有漏洞的代码，但是有的语言就能保证（在 safe 的范围内）不犯某些错误。比如有 gc 的语言，你就不会内存泄露，而 rust 编译器保证了内存安全和并发安全（ unsafe 以外）。
“人经验上去了，遇到的坑多了，BUG 自然就少了。”才是无稽之谈，世界上就没有不犯错误的人，更不乏反复犯同一个错误的人。

@3dwelcome 就比如搜索 chrome 内存安全，就可以看到一篇报道，指出：自 2015 年来，use-after-free 占 chrome 安全漏洞的 36.1%。内存问题仍然是 c++的主要问题之一。

@3dwelcome 并不是，如果这些泄露检测工具那么有用的话，windows 和 chrome 也不至于总能找到内存问题吧。微软和谷歌的报告也指出了，他们产品大部分的漏洞都是内存安全导致的。而换用 rust 后，也都有称赞 rust 确实解决了大部分内存安全的问题。

@wutiantong 也许说 UB 确实不准确，但是问题就在于 c++并不阻止你使用再次使用 moved 的对象，即使它有潜在的问题。就像 c++不阻止你再次使用 deleted 的指针。虽然某些次运行不会出错，但是总有出错的时候。
而且，c++就算用值语义，也不能避免内存错误，但是 rust 能检查出来。就比如有 std::vector<Foo> a={...}; const Foo &b = a[0]; a.clear();这时候就有潜在的悬浮引用 b 。

@ipwx 我是没看过哪个 c++的编译器能检查悬浮指针的问题的。微软和谷歌这些大量程序员用 c++的公司，都承认改用 rust 后，解决了绝大部分用 c++出现的内存错误。也许是他们的程序员脑子也不行吧。

@wutiantong C++也是有问题的，比如一个对象之前已经被 std::move 了，但 C++不会阻止你去访问一个 move 掉的对象，之后再调用这个对象的行为是一个 UB，相当于一个悬挂指针。
rust 显式定义生命周期的目的，不是为了计算对象什么时候 destroy （这一点 rust 也是 RAII ），而是为了保证你在函数内访问或返回一个对象的引用的时候，这个引用一定是 valid 的。

@GeruzoniAnsasu 就比如 c++里经典错误，一个重载函数签名有 int foo(bool a)和 int foo(std::string b)，请问 foo("abc")调用哪个版本。c++语法中就有很多陷阱，因此非常依赖 more more more effective c++之类的最佳实践。
如果让新手写 c++，出来的代码可能能编译能跑，但实际上却有存在内存错误或 UB 等等潜在问题，算不算友好呢。rust 除了强制所有权、引入了抽象数据类型(Option 、Result)等，我觉得最大的优势就是能编译的时候检查许多内存错误，只要改到编译器通过就行。

qq 就至少会自己判断终端，是微信太垃圾了。

@wyfyw 共享和镜像前两年随航就支持了。

@ysc3839 原来如此，但是我还是觉得如果真的要去掉 gil，这些静态对象的计数不是最大的问题。

@ysc3839 理论上来说这些对象都不会被回收，所以计不计数其实影响不大。

@ysc3839 None True False 都是不可变的，所以其实没什么问题，因为改变的只是引用。最大的问题是 list, dict, 包括 object 都是没锁的，现在去掉 GIL 改成细粒度锁，这些单进程的性能就会受影响。

@gggxxxx 不是效率的问题，你总得有个东西把底层的脏活干了。不然 java 这样的 gc 语言能自举自己吗，还不是要靠 c++来做解释器。而且像嵌入式、系统内核这种环境根本不可能用 gc 。

你用的是哪个版本？我并没有双击地址栏弹出书签栏的问题啊。