ELM与PureScript

我确信其中之一(或类似的东西)将成为未来，但现在就断言还为时过早。榆树社区发展非常迅速，它非常注重初学者友好和良好的开发体验(参见榆树创建者https://www.youtube.com/watch?v=oYk8CKH7OhE).最近的演讲)。这一重点保持了语言的简单性，并且已经做了大量的工作来使编译器错误变得有帮助和有指导意义。ELM还将与JS的通信限制在一个称为端口的接口上，基本上就是双方都必须解析和操作的消息传递。ELM还非常专注于客户端UI的编码(例如，角度或Ember，或者(大多数类似的)Reaction+Redux空间)。

PureScript也有类似的想法(一种编译为JS的静态类型函数式语言)，但背景不同，短期目标也不同。PureScript模块编译为CommonJS模块。PureScript函数编译为JS函数。FFI(与JS代码对话)更像是文字脚本或流，您可以在PureScript文件中定义外来类型，并告诉编译器信任您(而不是通过端口传递字符串)。

PureScript还旨在生成可读的JS，因此如果需要，可以在没有源映射的情况下使用和理解它。它也没有像ELM那样的运行时，从而产生更小、更灵活的输出(您可以针对浏览器、CLI应用程序、节点、AWS lambda等)。

PureScript还有一个更完整的类型系统，在某些方面比Haskell的更现代。对于没有Haskell经验的人来说，它不那么容易接近，但允许比Elm提供的更强大的抽象。

这是对PureScript及其JS输出的介绍，这些输出来自我最近在以下网站上展示的一次Meetup：https://www.youtube.com/watch?v=9a57V3bvzaI。

突出这种区别的一个小示例(ELM当前是一种UI构建语言，PureScript只是编写JS的另一种方式)是，当前ELM和PureScript编译器都是用Haskell编写的，而PureScript构建工具Pulp是用JS编写的。但是PureScript本身和Pulp都在用PureScript重写。我不知道有什么计划在不久的将来和榆树这样做。构建PureScript编译器时也考虑了编译到多个后端(JS、LLVM，可能还有Lua)。

ELM将慢慢采用来自PureScript的东西，反之亦然。要么Elm将成为最终跳到PureScript的垫脚石或学习平台，要么PureScript将被证明对于大多数人的需求来说学习曲线太陡，它将变得小众或消亡。同时，比赛将提高两种语言的水平：]