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