… 我还没见过手动「强化」你的软件比用 Rust 编写一个「同样好」的程序更快的情况。这只是反自动化。为什么要在每个项目中重复同样的工作并膨胀你的代码库，而让编译器为你承担这个负担呢？根据我的经验，Rust 让你比用其他语言编写生产级软件更快。> 将这种做法宣传为通用解决方案是不诚实的。我同意！在某些情况下，尽快发布一个有缺陷的原型是重要的。这是有空间的。但我认为，对于大多数需要长期维护的「严肃」生产软件来说，这不是情况。我认为 Rust 是编写这类生产软件的更好选择。
源讨论一个 Rust 的洞原帖 314 条评论 · 导入时统计我们很多人更喜欢自己处理一些复杂性，然后通过测试、持续集成、模糊测试等手段来解决，只要这意味着我们不需要为了看到代码运行而跳过各种障碍。 是的，Go、Python和Java非常容易上手编程。除非我们处理的是非常复杂的问题，比如下一代加密货币；），当Rust团队把他们的代码正确无误地编写好时，Go/Python/Java团队早就已经将产品发布给客户了。 如果有人想非常谨慎，相应地放慢速度，以确保他们完全没有内存错误，那也没关系。这有它的市场。但将这种做法宣传为一种普遍的解决方案是不诚实的。
完整原文把你的经验，加入这段讨论。
是的，问题在于，一旦你的软件跨越了成功的边界，它就会变成一种负担，而不是一种祝福。你现在被它束缚住了，你最好确保你对它以你的方式构建感到满意，因为你不久的将来不会离开这个项目。 也许Rust并不适合一次性项目，这也没关系。
完整原文认为需要Rust才能编写可靠的软件，从逻辑上来说不仅荒谬，而且事实上也与Rust只是安全关键软件或所有软件中微不足道、无关紧要的子集这一事实相矛盾。如果它真的是“编写此类生产软件的首选”，那么会有更多人使用它。 但事实并非如此，因为编译器不会为你承担负担。它将编写符合Rust生命周期管理设计的代码的负担交给了你，而这将是你永远要做的事情。 没有证据表明Rust软件的质量比等效的Swift或Java更高。内存安全技巧只对C和C++有效。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。