我对 Elm 不是很熟悉，但我已经对其进行了一些研究，而且我对 Reason 非常熟悉，所以我会试一试。我敢肯定这里会有不准确之处，所以请不要把我说的任何话当成事实，而是用它作为指针，让你自己更详细地研究什么，如果这对你很重要。

Elm 和 Reason 都是类似于 ML 的语言，具有非常相似的编程模型，所以我将重点关注它们的区别。

句法：

Elm 使用类似 Haskell 的语法，该语法是为 Elm 和 Reason 使用的编程模型设计（和/或演变）的，所以一旦你熟悉了它，应该可以很好地阅读和编写惯用代码，但看起来会非常不同并且对于大多数程序员来说是陌生的。

Reason 试图通过尽可能多地模拟 JavaScript 的语法来变得更平易近人，这对大多数程序员来说都是熟悉的。然而，它还旨在支持底层 OCaml 语言的整个功能集，这使得一些功能模式非常尴尬。

这方面的一个例子是函数应用程序语法，它在 Elm 中强调函数的柯里化性质 ( f a b)，并且非常适合组合函数和构建可读的 DSL。Reason 的括号语法 ( f(a, b)) 隐藏了这种复杂性，这使得它更容易进入（直到你不小心绊倒它，因为它当然在下面仍然不同），但是大量使用函数组合使括号变得混乱。

可变性：

Elm 是一种纯粹的函数式语言，理论上很好，但在实践中具有挑战性，因为周围的世界很少关心 Elm 对纯度的追求。我认为 Elm 对此的首选解决方案是通过在 JavaScript 中编写有问题的代码来隔离杂质，然后通过 Web 组件或端口在 Elm 中访问它。这意味着您可能必须使用一种单独且非常不安全的语言来维护大量代码，使用相当多的样板来连接它们，并且必须弄清楚如何通过端口的方孔等来安装圆形的东西第一名。

另一方面，理性是……务实的，我喜欢这样称呼它。你为了提高生产力和短期利益而牺牲了一些安全、理想和长期利益。在 Reason 中隔离杂质仍然是一种很好的做法，但是你不可避免地会走捷径来完成任务，这会在以后给你带来麻烦。

但是，即使您确实能够做到足够严格以隔离所有杂质，您仍然必须付出代价才能使语言发生突变。这个代价的一部分就是所谓的价值限制，你迟早会遇到，它会让你感到困惑和愤怒，因为它会拒绝直觉上应该工作的代码，只是因为编译器无法证明在某些时候不能涉及可变引用。

JavaScript 互操作性：

如上所述，Elm 提供了通过端口和 Web 组件与 JavaScript 互操作的能力，这些都是故意非常有限的。你曾经能够使用原生模块，它提供了更大的灵活性（以及在脚上开枪的能力），但这种可能性正在消失（至少对于平民而言），这一举动并非没有争议（但也考虑到哲学，不应该那么令人惊讶）。在此处阅读有关此更改的更多信息

Reason，或者更确切地说是 BuckleScript，提供了一组丰富的原语，可以直接绑定到 JavaScript，并且经常生成一个惯用的 Reason 接口，而无需编写任何胶水代码。虽然不是很直观，但一旦你掌握它就很容易做到。然而，它也很容易弄错并在稍后的某个随机时间点在你的脸上炸毁。无论您必须编写什么胶水代码来提供一个良好的惯用 API，都可以用 Reason 编写，并提供所有的安全保证，而不必编写不安全的 JavaScript。

生态系统：

由于 Elm 有限的 JavaScript 互操作性，生态系统相当小。提供 Web 组件的优质第三方 JavaScript 库并不多，而且自己做需要付出很多努力。因此，您将看到直接在 Elm 本身中实现库，这当然需要更多的努力，但通常会产生更高的质量，因为它们是专门为 Elm 设计的。

工具：

Elm 以其出色的错误消息而闻名。理性在很大程度上没有，尽管它努力做到。这至少部分是因为 Reason 本身不是编译器，而是构建在 OCaml 编译器之上，所以可用的信息是有限的，并且可能错误的表面积非常大。但它们也没有经过深思熟虑。

Elm 还有一个很棒的打包工具，它可以为你设置好所有东西，甚至检查你发布的包的接口是否发生了变化，以及版本凸起是否与语义版本控制相对应。Resaon/BuckleScript 只使用npm并要求您手动管理任何特定于 Reason/BuckleScript 的内容，例如bsconfig.json使用新的依赖项进行更新。

Reason、BuckleScript、它的构建系统和 OCaml 都在飞速发展。我还没有经历过从头开始编译需要超过 3 秒的项目，包括所有依赖项，而增量编译通常只需要几毫秒（尽管这并非完全没有用户友好性的成本）。据我了解，Elm 的性能并不那么好。

Elm 和 Reason 都有格式化工具，但 Reason 格式化的代码质量明显较差（虽然改进缓慢）。我认为这主要是因为它必须处理的语法要复杂得多。

成熟与衰败：

Reason 建立在 OCaml 之上，其根源可以追溯到 20 多年前。这意味着它有一个经过实战考验并证明可以在很长一段时间内工作的坚实基础。此外，它是一种主要由学术界开发的语言，这意味着一个功能可能需要一段时间才能实现，但当它真正实现时，它是坚如磐石的，因为它以理论为基础，甚至可能经过正式证明。不利的一面是，它的年龄和实验性质也意味着它聚集了一些难以摆脱的垃圾。

另一方面，榆树相对较新，官僚管理较少，可以更快地移动，并且不怕与过去决裂。这使得更苗条和更连贯，但也有一个不太强大的类型系统。

可移植性：

Elm 编译为 JavaScript，它本身非常可移植，但目前仅限于浏览器，对于 Elm 架构来说更是如此。这是一个选择，定位节点或平台不会太难。但据我了解，反对它的论点是，它会转移焦点，从而使其在其利基市场上变得不那么出色

Reason 基于 OCaml，实际上首先针对的是原生机器代码和字节码，但也有一个 JavaScript 编译器（或两个），使其能够针对浏览器、节点、电子、反应原生，甚至能够编译成单核。据说Windows支持有点粗略。作为一个生态系统，Reason 以 React 为首要目标，但也有一些库允许非常自然地使用 Elm 架构

治理：

Elm 是由一个人设计和开发的，他能够清楚地传达自己的目标和推理，并且全职工作并获得报酬。这使得最终产品连贯且设计良好，但开发缓慢，而且总线因素可能会使投资变得困难。

Reason 的故事有点复杂，因为它更像是一系列项目的总称。

OCaml是公开管理、设计和开发的，主要由学术界人士以及由各种基金会和商业支持者赞助的开发人员进行。

BuckleScript是一个从 OCaml 编译器派生的 JavaScript 编译器，由单个开发人员开发，该开发人员的目标和就业情况不明确，并且懒得解释他的推理或决定。开发在技术上更加开放，因为 PR 被接受，但缺乏解释和迟钝的代码库使其有效地封闭了开发。不幸的是，这也不会导致特别连贯的设计，而且总线因素也可能使投资变得困难。

Reason本身和ReasonReact由 Facebook 管理。公关人员受到欢迎，并且大量的 Reason 开发是由外部人员推动的，但大多数决定似乎是在某个密室中做出的。ReasonReact 的 PR，除了琐碎的错别字修复等，经常被拒绝，可能是有充分的理由，但通常很少解释。一个更好的设计通常会在稍后的某个时间从后面的房间出现。

elm - ReasonML 与 Elm

问题描述

解决方案

句法：

可变性：

JavaScript 互操作性：

生态系统：

工具：

成熟与衰败：

可移植性：

治理：

推荐阅读