我以前也听过别人有这种反应。我咨询过的一位Rust专家朋友告诉我："我不确定你是不是在尝试用Haskell的方式写Rust代码；" 我告诉他我遇到的模式在Java中既简单又常见。在我看来，在Rust中觉得困难或不可能的事情，其实是模块化和去除重复的基本模式，这些抱怨竟然不更常见，这真的令人震惊。我现在只有两个假设。第一，我提到的第二个问题只会在使用tokio时出现，这会导致你的顶层程序秘密地使用了一个从其他文件中你放置await的位置推导出的defunctionalized continuation数据类型，这可能不是Send的。如果你不使用tokio，你就不会遇到这个问题。第二……我被建议放弃去重，写很多复制粘贴的代码。…
源讨论数百万行Haskell：Mercury的生产工程原帖 233 条评论 · 导入时统计那是一次非常不寻常的Rust体验。我发现用Rust编写“应用代码”非常愉快。当然，Rust中有些地方不如其他语言那么方便（例如回调），但几乎所有语言都有类似的问题。
完整原文把你的经验，加入这段讨论。
> Rust爱好者是一群早期接触Rust的人，他们从未学习过传统的软件设计，不知道他们错过了什么 这绝对不是事实，而且这种说法是不必要的冒犯。 事实是，有些事情在Rust中更难，但a）通常这些事情最好避免（例如回调），b）由于其他好的特性，这值得权衡。 作为Haskell用户，你一定明白有时候让事情变得更难是值得的。是的，一切都是纯函数！这有很多好处。现在，我如何在这个深度嵌套的函数中添加日志？
完整原文> 在我看来，Rust中难以或不可能实现的是一些基本的模块化模式 很多东西是明确不允许的，要么是因为借用检查器不够聪明，要么是因为这种模式是不安全的（没有垃圾回收等）。 很多函数式/Haskell的模式根本无法直接转换为Rust。
完整原文像tokio这样的东西最令人困惑的事情之一就是远距离失败，比如在调用栈深处写了一个非Send的future，然后不得不弄清楚为什么你的顶层spawn不工作。当使用tokio时，我强烈建议开启一个非默认的lint：clippy::future_not_send。它强制所有future都是Send的，除非你选择退出，这在遇到错误时真的有助于保持推理的局部性。 顺便说一句，我主要写Rust，我不同意你第二点给出的建议，所以如果我是你的话，我会对这些建议持保留态度。
完整原文> Rust的爱好者是一群人，他们很早就接触了Rust，从未学习过传统的软件设计，不知道自己错过了什么，还有一群人是在传统的良好软件工程环境中成长起来的，但后来不断被Rust的「缺乏模块化」这个隐喻性的棒球棒击打，直到他们习惯了这种疼痛，把它当作生活中的常态。 哦，请吧。我是在使用了其他许多语言之后才接触Rust的。我从未遇到过“模块化”的问题。你对这些问题没有被更多讨论感到惊讶，那么最合理的假设是，你可能并不擅长Rust，你还没有真正掌握它——这没关系，我怀疑自己在Haskell上也不会很擅长。但不要侮辱我们，也不要假设你的体验是普遍的，而我们只是在否认。这非常傲慢。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。