我在StackOverflow上看到了这个ReasonML vs TypeScript问题，现在我想知道ReasonML和Elm的比较方式。
它们的异同是什么？什么时候应该使用哪一个？ 一个人比另一个人有什么优势？
答案 0 :(得分：67)
我对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中访问它。这意味着您可能必须使用一种单独的且非常不安全的语言来维护大量代码，将它们连接起来需要大量样板，并且必须弄清楚如何通过端口的方孔等来装入圆形物体。第一名。
另一方面，原因是... 务实，我喜欢这样称呼它。为了提高生产率和短期利益，您牺牲了一些安全性，理想和长期利益。在Rational中，隔离杂质仍然是一种好习惯，但是您不可避免地会捷径只是为了把事情做好，这会在以后给您带来麻烦。但是，即使您确实受到足够的训练以隔离所有杂质，您仍然必须付出代价才能使语言发生变化。这个价格的一部分就是所谓的the value restriction，您迟早会遇到这种情况，这会让您感到困惑和愤怒，因为它会拒绝直观上应该可以工作的代码，因为编译器是无法证明在某个时候不能涉及可变的参考。
JavaScript互操作性：如上所述，Elm提供了通过端口和Web组件与JavaScript进行互操作的功能，这些端口和Web组件故意受到限制。您过去曾经能够使用本机模块，这些模块提供了更大的灵活性（并有能力向自己的脚射击），但这种可能性正在消失（至少是针对平民），这一举动并非毫无争议（但也有争议）鉴于这种哲学，应该不会让人感到惊讶）。 Read more about this change here
Reason，或者更确切地说是BuckleScript，提供了一组丰富的原语，可以直接绑定到JavaScript，并且经常生成惯用的Reason接口，而无需编写任何胶合代码。而且虽然不是很直观，但是一旦完成它就很容易做到。但是，很容易弄错它，以后在某个随机点将其炸掉。无论您为提供良好的惯用API而必须编写的任何胶合代码，都可以用Reason编写，并具有所有安全保证，而不必编写不安全的JavaScript。
生态系统：由于Elm的JavaScript互操作性有限，因此生态系统很小。没有大量提供Web组件的高质量第三方JavaScript库，而您自己做需要付出很多努力。因此，您将看到直接在Elm本身中实现库，这当然需要花费更多的精力，但是由于它们是为Elm专门设计的，因此通常会带来更高的质量。
工具：Elm因其出色的错误消息而闻名。尽管尽力而为，但在很大程度上没有理由。这至少部分是因为Reason本身不是编译器，而是建立在OCaml编译器之上，因此可用信息有限，可能出现的错误的表面积非常大。但是他们也没有经过深思熟虑。
Elm还有一个很棒的打包工具，可以为您设置所有内容，甚至可以检查您正在发布的软件包的界面是否已更改，以及版本凹凸是否与语义版本控制相对应。 Resaon / BuckleScript仅使用npm，并要求您手动管理特定于Reason / BuckleScript的所有内容，例如使用新的依赖项更新bsconfig.json。
原因，BuckleScript，其构建系统以及OCaml都在快速发展。我还没有经历过任何项目都要花3秒钟以上的时间才能从头开始进行编译，包括所有依赖项，而增量编译通常只需要几毫秒（尽管这并非完全不花用户费钱）。据我了解，榆木的表现不尽人意。
Elm和Reason都具有格式化工具，但是Reason格式化的代码质量明显较差（尽管改进缓慢）。我认为这在很大程度上是因为它要处理的语法要复杂得多。
成熟度和衰变：原因基于OCaml，其根源可以追溯到20多年前。这意味着它具有扎实的基础，经过了实战测试，并证明可以长期使用。此外，这是一门由学者广泛开发的语言，这意味着一项功能可能需要一段时间才能实现，但是一旦加入，它就将成为坚如磐石，因为它是基于理论的，甚至可能是经过正式验证的。不利的一面是，它的年龄和实验性质也意味着它已经聚集了一些难以摆脱的残留物。
另一方面，榆树相对较新，官僚化程度较低，可以更快地行动，并且不怕与过去的冲突。这样可以使机身更纤巧，更连贯，但打字系统的功能也不太强大。可移植性：Elm可以编译为JavaScript，JavaScript本身可移植性强，但目前仅限于浏览器，甚至限于Elm Architecture。这是一个选择，并且以节点或平台为目标并不难。但是据我所知，反对它的观点是它会转移焦点，从而使其在利基市场上不那么出色
基于OCaml的原因实际上实际上首先针对本地机器代码和字节码，但还具有JavaScript编译器（或两个），使其能够针对浏览器，节点，电子，对本地做出反应，甚至具有以下功能： compile into a unikernel。 Windows支持虽然有点粗略。作为生态系统，Reason首先关注React，但也has libraries allowing the Elm Architecture to be used quite naturally
治理：榆树是由一个人设计和开发的，他能够清楚地传达他的目标和推理，并获得全职工作的报酬。这使最终产品设计得很连贯，但开发速度很慢，而且总线因素可能会使投资变得困难。
Reason的故事更为复杂，因为它更多地是一系列项目的总称。
OCaml 是公开管理，设计和开发的，主要由学者组成，也由各基金会和商业支持者赞助的开发人员进行。
BuckleScript 是从OCaml编译器派生的JavaScript编译器，由单个开发人员开发，该开发人员的目标和使用情况尚不清楚，并且不费心去解释其推理或决定。从技术上讲，开发是更开放的，因为可以接受PR，但是由于缺乏解释和模糊的代码库，因此有效地封闭了开发。不幸的是，这也不会导致特别一致的设计，并且总线因素也可能使此处的投资变得困难。
Reason 本身和 ReasonReact 由Facebook管理。 PR受到欢迎，并且大量的理由开发是由外部人推动的，但是大多数决定似乎是在某个地方的后台进行的。除了琐碎的拼写错误之外，ReasonReact的PR经常被拒绝，这可能是有充分理由的，但通常没有什么解释。然后通常会在一段时间后从后室出现更好的设计。