Java是 "强类型 "的，但来自java这种督促并没有让我的代码结构变得更好。例如，Java能让你使用UnsignedInteger类型，但人们通常不会使用它。相反，建立“类”的感觉是很麻烦的，有很多模板。
Rust的独特之处在于它强迫你一次只能有一个可变的“引用”，但我怀疑仅凭这一点就能让你构建出伟大的代码。反而那些通过缺少“引用”来避免这种情况的语言，并不能让我写出好的代码。
我确实注意到Rust是完全不含糊的，这有助于我思考某些优化问题。但是，这仍然不足以让我写出伟大的代码。
看起来，多种此类属性的结合使Rust促使用户写出更好的代码。我已经意识到，在用其他语言编码时，我有点像 "crack到它能用为止"。在运行时测试，沿途修复任何错误。Rust似乎给了我一个备选方案，以涵盖各种边缘情况，而不需要运行它们。
现在我已经达到了这样的程度：当我在工作中得到一个任务时，我可以先用Rust写出来，并确保编译器满意--我甚至不需要运行代码，只是编译就够了--然后把代码翻译成我的目标语言。这样一来，我就避免了 "crack它直到成功 "的环节，因为它就是成功的。
不知何故，在与 Rust 编译器斗争时，“crack它直到它工作”变成了“重写它直到它结构良好”。就像他们构建了你如何与编译器对抗一样，所以它不再是一个黑客。
这里的关键见解是，严格控制内存所有权通常会产生更好的代码。目标不是强迫程序员编写更好的代码，但更好的代码通常是内存安全的。具有相同目的的事物倾向于共享相同的生命周期、作用域等。
我发现异步编程更是如此。如果您可以在函数调用和内存线程中保持安全，那么您可以在并发和并行代码中保持安全。
我记得在 2010 年代，有多少 js 开发者抱怨“回调地狱”之类的东西。事实是，如果您无法在异步调用中推理内存安全性，在深度嵌套的闭包作用域内捕获大量可变变量，那只会是地狱般的。每个人都认为 Promises 拯救了它们，但如果旧代码库让所有东西默认不可变，它们的大部分问题可能会消失。
Rust通过使错误的事情变得更加困难来激励做正确的事情。
很难确定究竟是什么让 Rust 在设计代码方面做得更好，但我想到了一个列表：
- 数据优先——Rust 有数据优先的方法，而其他编程语言有“类优先”或“函数优先”的方法。这可能会影响我们从一开始就进行代码设计的方式，并成为关注最重要的数据结构的强制因素。
- 缺乏继承——起初这对我来说很难，但这是我们都需要洗的冷水澡。干净的结构和枚举/变体模型使事情变得更加直接和明确，简化了未来的代码。有时它仍然感觉缺失，但它可能只是一个遗留的习惯。
- Orientation Dogma Free - 与 2 相关，但在拒绝 OOP 之后，Rust 甚至没有尝试跳入 FP 教条。我认为 FP 正在重复 OOP 所犯的许多错误。时间会证明一切，但我预测几年（或更早）会出现 FP 疲劳。并不是说某些函数式范式没有前途，Rust 应该有更多，但教条式的做法适得其反。
- 匹配模式——整个匹配模式改变了我的编程风格，每个分支都是意图驱动的，而不是一些语言强制分支的必要性。
- 模块系统- 模块的直观文件夹结构，同时仍然允许完全的灵活性，并记住模块应该导出多个结构，甚至允许重新导出以隐藏下游布局细节。这个模块系统有很多。
- 端到端工具链- 从单元测试（具有私有访问权限）、集成测试、示例、文档，甚至完全融入基准测试。这有助于我们做我们早就应该关心的事情。
Rust 并不一定会让你写出“更好”的代码。它促使您编写更多面向编译时的代码，而不是面向运行时的代码。这使得编写面向运行时的代码变得困难，并且由于面向编译时的代码更适合静态分析，因此您可以更早地发现错误。
有许多软件工程和算法问题可能在面向编译时的代码之外有最好的解决方案，但对于大多数人来说，大多数时候（在 leetcode 之外）大多数问题，他们最好编写面向编译时的解决方案。