Scalaはプライムタイムの準備ができていますか？[閉まっている]

Scalaを使ってささいなことをいくつかやったので（ "hello world"と不自然なアプリケーションが大好きです！）、開発をサポートするツールの成熟度と、一般的な適用可能性については疑問に思っています。ツールセットは準備ができていますか？Scalaはエンタープライズ/ビジネスアプリケーションでの使用に適していますか？自明ではないプロジェクトで「あなた」はそれを使用しますか？

私の（おそらく根拠のない）懸念事項のいくつかは次のとおりです。

• IDEおよびツールセットは、.netおよびjavaアプリケーションを開発するために必要なものと同じくらい豊富ですか（ScalaのEclipseはJavaのEclipseと比較して制限されているようです）？
• ビルド/ CI /テストツールセットはScalaを効果的に処理できますか？
• その言語で書かれた（奨励された）簡潔なコードはどの程度保守可能か？
• Scalaの経験を持つ開発者を見つけることは可能ですか？
• オンラインのリファレンスや、言語の「イントロ」以上の本を通して助けを得るのに十分なクリティカルマスはありますか？

結論として、エコシステムは現在使用できるほど成熟しているか、それとも進化の様子を待つほうがよいのでしょうか？

編集：「non-trivial」は、複数年、複数リリース、10〜20人の開発者プロジェクトだとしましょう。

ScalaがGuardianおよびTwitterで実際に使用されているのは事実ですが、根本的な懸念が1つあります。

Javaの人気の多くは、比較的読みやすく保守しやすいという事実に基づいています。Scalaには、さまざまなスタイルで記述できるという問題があります。オブジェクト指向スタイルと機能スタイルはここでは明らかな分割ですが、Scalaの3つのレベルについて話すと、より複雑になります。

あなたのチームと潜在的な新規採用者全員が同じスタイルに従うこと、そしてスタイルがあなたが実際に効果的な開発者を雇うことができるほどシンプルであることを確認する必要があります（誰もがトップ2％を雇えるわけではありません） 。

ツーリングのサポートもまだ十分ではありませんが、このギャップはすぐに解消されると思います。TypeSafeクラウドからScalaスタック全体のサポートを受けることもできます。Scalaはそのニッチを切り開くと思いますが、レベルが実際に言語/コンパイラ/その他に組み込まれるまで、最初の1-2年間の生産性が向上した後、チームにメンテナンスの頭痛が降りかかっています。

詳細については、関連する回答を参照してください。

現在、ScalaはTwitterおよびThe Gaurdianで使用されているため、重要なアプリケーションに確実に対応できます。

Scalaプログラマーは非常に意欲的で、おそらく非常に優秀です。新しい言語を選択することは、才能を引き付ける素晴らしい方法です。

もちろん、ScalaプログラマーはプロのScalaの経験を持たないことが多く、使用するイディオムにはさまざまなものがあります。Haskellのような純度を目指して努力する人もいれば、クロージャを備えたJavaと見なす人もいます。したがって、一貫したコーディング標準と規則を開発するには、おそらく時間がかかるでしょう。

多くのJavaツールはうまく機能しますが、おそらくIntelliJ IdeaはEclipseよりも投資する価値があるでしょう。

全体として、プロジェクトを制御できれば、それは良い選択かもしれません。これが大規模な保険会社の一部である場合、「すべてのプロジェクトはMavenによって構築され、WebSphereにデプロイされる」などのアーキテクチャガイドラインがある場合、問題が発生する可能性があります。（この特定のルールが問題になると思う理由はありませんが、そのようなルールの急増はある時点であなたをつまずかせるかもしれません。）

私の印象では、「Java」などの「従来の」言語に付属するエコシステムの多くは、その不器用さを補うことを目的としているということです。

問題は、特定の言語（Scala）にいくつのツールがあるかではなく、その言語の既存のツールが参照言語（Java）の既存のツールより優れているかどうかです。100種類の平凡なツールでは得られないため、1つの優れたツールで何が得られるのか。そして忘れてはならないのは、言語自体がこれらのツールの一部であるということです。

言語の宣言性

• バグの量と深刻度に反比例します。これが、Javaがバグの作成に優れている理由であり、バグを回避および追跡するには多くのツールが必要です。
• 生産性に比例するため、Javaは非常に冗長であり、多くのコードジェネレーターおよび同様のツールが必要です。

例えば、私はかつてRubyの男による恐ろしいブログ記事を読みました。彼は静的型付けは無意味だと主張しました。なぜならあなたのテストは型の安全性をカバーするからです。これは明らかに、表現力豊かな静的型システムをまだ使用していない人から来ました。言語セマンティクスですべての型の関係を表すことができ、実行するのにあまり労力がないと仮定すると（そして、ほとんどの現代の言語は型推論をサポートしているので、そうではありません）、すべて無料で取得します。

考えをもう少し進めるために：ユニットテストは、ユニットが指定どおりに動作することを保証します。言い換えると、ユニットテストは実行可能な仕様です。ただし、宣言型プログラミングにより、ユニット自体は実行可能な仕様です。繰り返しますが、無料で何かを入手できます。

私が言おうとしているのは、言語機能があなたのために何ができるかを過小評価すべきではないということです。そして、あなたが本当にフィールドでそれらを試さない限り、あなたは決して理解しないでしょう。

元の質問に戻ると、Scalaの既存のツールはJavaよりも優れているのでしょうか？言いにくい。何をしたいかによって異なります。私たちは皆、言語がかなり良くなっていることに同意すると思いますが、今の質問は、あなたのビジネスエリアでどれだけ良いエコシステムを見つけるかということです。
Webの場合、Liftは実際に使用する堅実なオプションです。デスクトップまたはモバイルについて知らない。

「非自明」は、複数年、複数リリース、10〜20人の開発者プロジェクトだとしましょう。

それは多くのリスクです。報酬には価値があるはずです。エンタープライズビジネスアプリと中規模から大規模のプロジェクトの世界では、通常、リスクを負うことは制限されています。むしろ、対処するのに十分なリスクがすでにあります...予測可能性がより重要です。

私は養子縁組がそのように働くことを疑います。

POC、重要ではないコンポーネント、テスト、または他の選択肢よりもScalaがはるかに適切に対処していると思われる部分など、リスクが含まれる部分で作業する少数の人々として開始する可能性が高いたとえば、アクター）...そしてツールが成熟するにつれて、コミュニティが成長し、社内でノウハウが成長すると、それが拡大する可能性があります。

Javaランタイムを活用することで、Scalaは確実にプライムタイムの準備が整います。Scalaアプリケーションをデプロイできる場合、バイトコードが生成されると、その特定のバージョンのJavaランタイムで常に動作するはずです。Scalaベースのライブラリは、あなたがよく知っている他のJavaサードパーティライブラリと同様に機能します。

IDE、ビルドツール、その他すべての点で、ScalaにはJavaと同じレベルの増殖はありません。したがって、多くのScalaベースのフレームワークやScalaベースのツールはありません。Scalaの人気の高まりよりもJavaの人気のほうが重要です。Scalaには、Scala IDEやsbt、ビルドツールなどの機能ツールがあります。しかし、それらは他の純粋なJavaヘルパーツールのいくつかほど洗練されていません。

@huynhjlと@FarmBoyからのチェリーピッキングポイント：

• 十分な数の経験豊富なScalaプログラマーを見つけるのは難しいかもしれません。

• Scalaの「ベストプラクティス」の教義はまだ進化しています（*）。

• スタイルガイド、規則などはまだ進化しています（*）。

• ツールのサポートはまだ進化しています（*）。

これらをまとめると、あなた自身が（自分自身で）尋ねるべきより良い質問は、あなたの組織が「自明でない」プロジェクトでScalaを使用する準備ができているかどうかです。「まだ進化している」多くのことで大きなプロジェクトを行うことに対処できる人がいますか？逆に、最初に小規模なプロジェクトを行う方が良いでしょうか？

（*実際、ほとんどの言語は、これらの点の1つ以上でまだ進化しています。ここでの問題は、変化/変化の速度です...そして、チームがそれに対処できるかどうかです。）

Good StuffのDavid Pollakが、Functional Languages will Ruleというタイトルの優れたブログ投稿（今年はそうではありません）を公​​開しています。プライムタイム。

enterpriseとnon enterpriseプログラムの違いを理解できませんでした。

私は自宅と同じプログラムを仕事で使っています。私は暇なときに平凡なプログラムを使用しません-どうしてですか？

非専門プログラムとは何ですか？互換性の問題のため、またはユーザーが何か新しいものを学習することを拒否したために、ユーザーがよく知らなかったため、貧弱なアプリケーションが使用されているのを見てきました。

しかし、それは時代遅れのソフトウェアの問題であり、目標は、開発者が念頭に置いていた-プログラムが書かれた言語ではなく、プログラムが書かれている言語で考え始めると、すでに終わっています：失敗します。

Enterprise-applicationは、マーケティング用語であり、真剣な議論には役立ちません。

そして、どの言語であなたが仕事をしたかを知っているのはどの顧客ですか？時々彼らは気にし、時々気にしない。

言語の成熟度に関連する質問があるかもしれませんが、すべての種類の企業およびすべてのアプリケーションについて質問に答えることはできません。