プログラマにとって違和感がなく使えると思います。キーワードが特殊なのと、これからあまり流行ると思えないので微妙です。ついては関数型言語的な考え方など学ばなければならないことが多いと思います。それぞれの言語で書かれたクラスやメソッドを互いにシームレスに利用することが出来ます。書いてみるのがいいと思います。準公式言語のようなものです。比べても遜色ないレベルのサポートを受けることができます。使うのがいいと思います。流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。コードだけ使うことができます。そのため、既存のプロジェクトに対しても導入のハードルは低いです。モードになっていないので注意して下さい。指定する必要があります。オンにすることが推奨されています。移行できなかった人も多いかもしれません。できるだけ後方互換が保たれる予定です。使う理由がなくなりそうです。コードと互いに連携することができます。側で使うようなこともできます。書いてみるのがいいと思います。使っているなら、特に新しくインストールしなければならないものはありません。コードを書くことができます。移行できなくても今すぐ始めることができます。使えるコメント構文は実行時にはただのコメントとして解釈され、動作に一切影響を与えないので、既存のプロジェクトにも気軽に導入できます。ついて学ぶには次の各記事が参考になります。場合はうまくいきません。コードと連携することができません。するというのは難しいでしょう。書いても問題ないはずです。試してみるのが良いでしょう。フレームワークもあるので、小規模な新規プロジェクト等で試してみるのも良いかもしれません。眺めているときちんと伝わっていないと思われることがあったので簡単に回答します。同じ趣旨でより多様な質問に丁寧に回答しているので、下記で足りなければそちらも御覧下さい。良いものでもすぐに普及するとは限りません。オブジェクト指向やラムダ式、高階関数が多くの言語に取り入れられるまでにどれだけの時間がかかったか思い出して下さい。この可能性は否定できないですが、この論法では新しいものは何も導入できないことになってしまいます。等でテキトーに値を与えない等)、たとえばオブジェクト指向と比較しても難しくないと思います。オブジェクトには致命的な問題があります。値が存在しないときに期待される挙動は文脈によって異なるということです。オブジェクトを実装することはできません。して振る舞って欲しいのかは文脈によって異なるからです。詳しくは本文に追記したのでそちらを御覧下さい。エラーを表すべきではないと思います。返す場合には、できるだけ早い段階でエラー処理をすべきです。モナドについて詳しい人には改めて説明する必要はないと思いますし、詳しくない人に対してモナドの話まですると混乱するだけかと思い、本投稿では省略しました。