web-dev-qa-db-ja.com

ReasonMLとTypeScript

ReasonML（ https://reasonml.github.io/ ）とTypeScript（ https://www.typescriptlang.org/ ）のトレードオフは何ですか？

typescriptreasonbucklescript
44
noname

JavaScriptをターゲットとする多くの言語が現在あります。どちらを選択するかは、ニーズと イディオム に応じて異なります。

JavaScriptには動的型システムがあります。一部の開発者は静的なものを好みます。

  • TypeScriptまたはHaxeは、静的に型付けされ、JavaScriptに変換するだけの新しい言語でこれを解決します。

  • フローは、同じ問題をターゲットとするJavaScriptプリプロセッサですが、新しい言語を学ぶ必要はありません。型システムのみが必要な場合は、このアプローチを好みます。

一部のJS開発者は、より多くの機能的プログラミングイディオム（代数的データ構造、不変性、パターンマッチングなど）を使用します。多くのプログラミング言語で実行できます（OCaml、Haskell、ReasonML、F＃、Scalaなど）。

  • ReasonMLはOCamlの構文で、BuckleScriptを使用してネイティブまたはJavaScriptにコンパイルできます。 Reasonで達成できることはすべて、OCamlでも達成できますが、ReasonML構文はJSXを受け入れます。 ReasonMLは、node.jsアプリ、react.jsアプリ、ネイティブアプリを簡単にターゲットにできます。

TypeScriptは、JavaまたはC＃の世界から来た人であれば簡単に習得できます。

ML言語（OCamlまたはF＃）で開発したことがない場合、ReasonMLの学習は困難です。

私のアドバイス：

  • 静的型システムだけが必要な場合は、TypeScriptを検討する必要があります

  • React.jsまたはreact-nativeアプリを実行するために型システムが必要な場合、ReasonReactはreact.jsよりも大幅に改善されているため、ReasonMLを検討する必要があります

  • Jsにコンパイルする関数型プログラミング言語が必要な場合は、ReasonMLを検討する必要があります

50
Thomas

多くのトレードオフがありますが、その多くは技術的にはOCamlであるため、Web上のこの奇妙なJavaScriptニッチをほとんど考慮せずにネイティブにコンパイルされた言語であるというOCamlの25年の歴史からほとんどの設計決定を継承しているためです。

しかし、ReasonMLのサウンドと柔軟な型システムと、包括的な静的チェックを既存のJavaScriptコードベースに簡単に「忍び込ませる」TypeScriptの能力との間に最大のトレードオフがあると思います。

TypeScriptの型システムは、音が鳴らないように明示的に設計されているため、ほとんどの場合手に入れられますが、多くの保証を与えることはできません。型システムを完全に信頼することはできません。これは、適切な静的型システムを持つことの最大の利点の1つです。

TypeScriptは、ランタイムタイプ情報を回避するという決定によっても制限されます。これは、パターンマッチングなどの機能と、ReasonMLで型指定されたデータを操作する主な利点に必要です。

一方、ReasonMLでは、ReasonMLと既存のJavaScriptコードとの境界を明示的に定義する必要があります。型はある程度推測できますが、コンパイル時に決定する必要があります。これは、特に既存のJavaScriptコードベースが変換されるときに境界が徐々に移動する場合、JavaScriptの相互運用をより面倒にします。また、JavaScriptで行われる奇妙なものを入力する方法が常に明らかであるわけではありませんが、通常は可能ですが、とにかくすべてがReasonMLに変換されるまで一時的なものです:)

明らかに私は偏見がありますが、少なくとも実際にはそうではないので、明確な勝者を選ぶことにはならないことを願っています。少なくとも世界が完璧でない限り、これは大きなトレードオフです。

35
glennsl

大規模なアプリケーションでは、ReasonMLでデフォルトで提供される多くの機能が必要になります。厳密な型、JSONをエンコード/デコードする場合のランタイム検証、高速コンパイル時間、不変データ。

TypeScriptでは、以下を追加する必要があります：

  1. ImmutableJS +そのタイピング。
  2. json-schema +のような実行時バリデーター。次に、TypeScriptで型を記述し、json-schemasでスキーマを定義する必要があります。すぐに同期がとれなくなる可能性があります。
  3. 変数が特定の型である場合に違いを伝えるためのいくつかの狂ったハック（TSの公式ドキュメントのように： https://www.typescriptlang.org/docs/handbook/advanced-types.html 、Paragraph "ユーザー定義のタイプガード」）。このチェックは、a.swim！== undefinedのような副作用を使用して行われます。 6か月後には、この「if」ステートメントにさらに多くのチェックが含まれます。
  4. 使用するパッケージに、公式で保守されている型定義がある場合、幸運です。または、カスタムタイピングになります。
  5. JS + TSでハイブリッドアプリを開発する場合、TSコンパイラは、プロジェクトの他の部分にインポートできるバンドルされた最終的なd.tsファイルを作成できません。 dts-bundle のようなツールにバンドルされている個別のd.tsファイルを作成する必要があります。 TSにすべてがある場合、この問題は該当しません。
  6. 大きなアプリは、TypeScriptでコンパイルするのに時間がかかります。

ReasonMLの場合：

  1. 不変データは言語にあります。
  2. ランタイムバリデータが存在します（ bs-json はデフォルトでそれらを持っています）
  3. パターンマッチングは、これらのクレイジーなチェックからあなたを救います。
  4. 使用したいnpmパッケージにBuckleScriptバインディングがあれば幸運です。
  5. なし。
  6. ReasonMLのコンパイルは非常に高速です。
17
gladimdim

（メモのみ）

すべての実用的な側面を脇に置きます。

ML言語ファミリはSystem-Fと呼ばれる型理論に基づいています。これは、たとえばPurescriptやHaskellでも使用されています。

TypeScriptにはこのような十分に確立された基盤がありません代わりに、多くの特別なビットを持つ新しい実験的な型システムを使用します（「形式化」されているかどうかはわかりません）。

そのため、表面的にはTSのアプローチは「実用的」に見えるかもしれませんが、必要以上に複雑になります。システムFにはシステムを構成する少数のルールがあり、非常に一般的ですが、そのTSの「理論」について推論するのは簡単です。少ないほうがいいですね。

また、System-Fの学習に費やされた努力は時代を超越しており、Purescriptなどの他のより強力な言語に変換されます。

9
wires

これらは非常に異なります。

  • ReasonMLは、JavaScriptにコンパイルされるJavaScriptとは異なる言語です
  • TypeScriptは、JavaScriptにコンパイルされる厳密なJavaScriptのスーパーセットです。

タイプセーフなコードを書きたい場合は、両方とも優れた選択肢です。

  • タイプセーフJavaScriptを記述したい場合、TypeScriptがオプションです。

  • タイプセーフでJavaScriptにコンパイルされる言語を作成する場合、ReasonMLは多くのオプションの1つです。 ReasonMLの場合のいくつかの言語はOCAMLです。

もっと

私の偏った意見： https://medium.com/@basarat/TypeScript-won-a4e0dfde4b08

5
basarat

Reason MLには機能的なファーストスクールが付属しています。もしあなたがそのような考えを持っているなら、それがGoへの道です。一方、TypeScriptはfpを実行でき、コミュニティサポートも良好です。ほぼすべての一般的なライブラリにはTypeScriptの型付けがあります。 fpts（ https://github.com/gcanti/fp-ts/blob/master/README.md ）を使用することを好みます。 TypeScriptのfpのすべての長所が提供され、ランタイムチェックも含まれます。 tsでは、型コンストラクタは大きなミスです。あなたがそれと一緒に暮らすことができるなら、tsを選んでください。

1
Abdul Kader Jeelani