ReasonML与TypeScript

Question

ReasonML（https://reasonml.github.io/）和TypeScript（https://www.typescriptlang.org/）之间的权衡是什么？

Answer 1

现在有很多针对JavaScript的语言。 选择其中一个取决于您的需求以及您感到满意的idioms。

JavaScript有一个动态类型系统。一些开发人员更喜欢静态的。

• TypeScript或Haxe使用静态类型的新语言解决了这个问题，并且只转换为JavaScript。

• Flow是一个JavaScript预处理器，它针对同一个问题但不需要学习新语言。如果你只需要一个类型系统，我更喜欢这种方法。

一些JS开发人员需要更多并使用更多的函数式编程习惯用法（代数数据结构，不变性，模式匹配......）。很多编程语言都可以做到（OCaml，Haskell，ReasonML，F＃，Scala，......）。

• ReasonML是OCaml的一种语法，可以通过BuckleScript编译为本机或JavaScript。除了ReasonML语法接受JSX之外，使用OCaml也可以实现使用Reason实现的所有功能。 ReasonML可以轻松定位node.js app，react.js应用程序或本机应用程序。

如果您来自Java或C＃世界，TypeScript很容易学习。

如果您从未使用ML语言（OCaml或F＃）开发，那么ReasonML更难学习

我的建议：

• 如果您只需要静态类型系统，则应考虑使用TypeScript

• 如果您需要类型系统来执行react.js或react-native应用程序，您应该考虑ReasonML，因为ReasonReact是对react.js的巨大改进

• 如果你需要一个编译成js的函数式编程语言，你应该考虑ReasonML

Answer 2

有许多权衡取舍，其中许多源于ReasonML技术上只是OCaml，因此继承了OCaml 25年历史上的大多数设计决策，这些历史是一种本地编译的语言，很少关注这个奇怪的JavaScript利基网络。

但是我认为最大的权衡是在ReasonML的声音和灵活类型系统之间，以及TypeScript能够轻松地将全面的静态检查“偷偷摸摸”到现有的JavaScript代码库中。

TypeScript的类型系统明确地设计为不合理，因此虽然它会在大多数时间为您提供帮助，但它无法为您提供许多保证。你真的不能完全信任类型系统让你的背部，这是拥有一个适当的静态类型系统的最大优势之一。

TypeScript也受限于避免运行时类型信息的决定，这对于模式匹配等功能是必需的，并且是在ReasonML中使用类型化数据的主要好处。

另一方面，ReasonML要求明确定义自身与现有JavaScript代码之间的边界。类型可以在某种程度上被推断，但它们仍然必须在编译时确定。这使得JavaScript互操作变得更加费力，尤其是当边界随着现有JavaScript代码库的转换而逐渐移动时。在JavaScript中输入一些奇怪的东西并不总是显而易见的，但它通常是可能的，并且希望只是暂时的，直到所有东西都被转换为ReasonML：）

显然我有偏见，但我希望这并不是因为选择一个明显的赢家，至少因为确实没有。这是一个重要的权衡，至少只要世界并不完美。

Answer 3

在大型应用程序中，您需要很多功能，这些功能在ReasonML中默认提供：严格类型，运行时验证（如果您编码/解码JSON），快速编译时间，不可变数据。

在TypeScript中，您必须添加：

1. ImmutableJS +它的类型。
2. 运行时验证器，如json-schema +其类型。然后，您必须在TypeScript中编写类型，并在json-schemas中定义模式。他们很快就会失去同步。
3. 如果变量是特定类型的话，有些疯狂的黑客可以区分（例如TS的官方文档：https://www.typescriptlang.org/docs/handbook/advanced-types.html，段落“用户定义的类型保护”）。这种检查是使用像.swim！== undefined这样的副作用完成的。在6个月内，这个'if'语句将包含越来越多的支票。
4. 如果您使用的软件包具有官方和维护类型定义，那么您很幸运。或者你最终会得到自定义类型。
5. 如果您在JS + TS中开发混合应用程序，那么TS Compiler无法创建捆绑的最终d.ts文件，您可以在项目的其他部分导入该文件。您必须编写单独的d.ts文件，这些文件由dts-bundle等工具捆绑在一起。如果您拥有TS中的所有内容，则此问题不适用。
6. 大型应用程序需要花费大量时间才能通过TypeScript进行编译。

使用ReasonML：

1. 不可变数据使用该语言。
2. 存在运行时验证程序（默认情况下bs-json有）
3. 模式匹配可以帮助您避免这些疯狂的检查。
4. 如果您想要使用的npm包具有BuckleScript绑定，那么您很幸运。
5. N / A
6. ReasonML编译非常快。

Answer 4

（只是一个音符）

将所有实际问题放在一边；

ML语言家族基于称为System-F的类型理论，例如，Purescript和Haskell也使用这种语言。

打字稿缺乏如此完善的基础，而是使用具有许多特殊位的新实验型系统（我什至不确定它是否“形式化”）。

因此，从表面上看，TS的方法似乎是“实用的”，但它引入了必要的更多复杂性。系统F具有构成系统的少量规则，它非常笼统，但更容易推断出TS的“理论”。少即是多。

此外，学习System-F所花费的时间也是永恒的，可以转化为其他更强大的语言，例如Purescript。

Answer 5

非常不同。

• ReasonML是一种与JavaScript不同的语言，可编译为JavaScript
• TypeScript是JavaScript的严格超集，可编译为JavaScript

如果你想编写类型安全代码，两者都是很好的选择。

• 如果您想编写typesafe JavaScript ，则可以选择TypeScript。

• 如果您想编写可以编译为JavaScript的typesafe 某种语言，那么ReasonML是众多选项中的一种。 ReasonML案例中的某种语言是OCAML。

更多

我的偏见：https://medium.com/@basarat/typescript-won-a4e0dfde4b08

Answer 6

Reason ML带有功能性第一学堂，如果您以这种思维定势，那就去了。而打字稿可以做fp并且也有很好的社区支持。几乎所有流行的库都有打字稿类型。我更喜欢使用fpts（https://github.com/gcanti/fp-ts/blob/master/README.md）。它在打字稿中提供了fp的所有优势，其中还包括运行时检查。尽管类型构造函数在ts中是一个很大的小姐。如果可以接受，请选择ts。