Erlangを使用して「反対」を決めたのはなぜですか？
あなたは実際に「試してみた」（それについての記事を読むだけでなく、プログラムされたという意味）Erlangとプロジェクトに対してそれを決定しましたか？もしそうなら、なぜですか？また、古い言語に戻るか、F＃、Haskell、Clojure、Scalaなどの別の関数型言語を使用することを選択した場合は、これも重要です。
Haskellの驚くべき型システムの単純な美徳のために、Erlangからの個人的なプロジェクトのためにHaskellに戻りました。 Erlangには、物事がうまくいかないときに対処するためのツールがたくさんあります。 Haskellは、そもそもあなたが間違ったことをしないようにするツールを提供します。
強力な型システムを持つ言語で作業する場合、コンパイルするたびにコードに関する無料の定理を効果的に証明します。
また、Haskellのタイプクラスマシンから多数のオーバーロードシュガーを取得しますが、それは私にとって非常に二次的なものです。 category-extras）。
Erlangが大好きです。Erlangのチャンネルと簡単な拡張性が大好きです。これらが私が必要とするものであるとき、私はそれに向きます。ハスケルは万能薬ではありません。私は、スペース消費のより良い運用上の理解を放棄します。魔法のワンパスガベージコレクターを放棄します。私はOTPパターンとそのような簡単な拡張性をあきらめます。
しかし、私が一般的に言われているように、Haskellでタイプチェックを行った場合に正しいと思われるセキュリティブランケットを放棄するのは困難です。
Haskell、OCaml、および（現在）F＃を使用しているため、Cのような構文の欠如とは何の関係もありません。むしろ、Erlangをスキップします：
- 動的に型付けされます（Haskellの型システムのファンです）
- 「実際の」文字列型を提供しません（理由はわかりますが、これがまだ言語レベルで修正されていないのは面倒です）
- 貧弱な（不完全またはメンテナンスされていない）データベースドライバーを持つ傾向がある
- バッテリーは含まれていないため、これを修正するためのコミュニティはありません。もしそうなら、それはあまり目立ちません。 Haskellには少なくともHackageがあり、それが他の言語よりもその言語を選択しているのだと思います。 Windows環境では、F＃がここで究極の利点を持ちます。
おそらく今は考えられない他の理由がありますが、これらは大きなポイントです。
Erlangを避ける一番の理由は、プログラミングの機能的な方法にコミットできない場合です。
私は数週間前に反Erlangのブログを読みましたが、作者のErlangに対する批判の1つは、同じ引数で関数を呼び出すたびに関数が異なる値を返すようにする方法を理解できなかったことです。彼が本当に理解していなかったのは、Erlangが意図的にその方法であるということです。それが、明示的なロックなしで複数のプロセッサでErlangがうまく動作する方法です。純粋に機能的なプログラミングは、副作用のないプログラミングです。 Erlangをアームツイストして、私たちの不満のブロガーが望むように動作させ、副作用を追加することができますが、そうすることでErlangが提供する価値を捨てることができます。
純粋な関数型プログラミングは、プログラミングする唯一の正しい方法ではありません。すべてが数学的に厳密である必要はありません。アプリケーションが「関数」という用語を誤用する言語で記述されるのが最適であると判断した場合、Erlangをリストから除外することをお勧めします。
私はすでにいくつかのプロジェクトでErlangを使用しています。私はよく安らかなサービスにそれを使用します。ただし、使用しないのは、Ruby on Railsの方がはるかに優れています。 Erlangほど優れたツールはありません。
また、Erlangで書かれたいくつかのアプリケーションを使用します。 CouchDBとRabbitMQを少し使用し、EJabberdサーバーをいくつかセットアップしました。これらのアプリケーションは、その分野で最も強力で、最も簡単で、柔軟なツールです。
ErlangがJVMを使用しないため、Erlangを使用したくないというのは、私の考えではかなりばかげています。 JVMは、世界ですべてを行うのに最適な魔法のツールではありません。私の考えでは、さまざまなツールのコレクションから選択でき、単一の言語やフレームワークにとらわれないことが、専門家とコードモンキーを区別するものです。
PS：コンテキストでコメントを読み戻した後、oxbow_lakesをコードモンキーと呼んでいるように見えました。私は本当にそうではなかったし、彼がそのようにそれを取ったならば謝罪します。私はプログラマーのタイプについて一般化していましたが、彼のコメントに基づいて個人をそのような否定的な名前と呼ぶことは決してありませんでした。 JVMをある種の取引ブレーカーにしないように勧めていますが、おそらく彼は優れたプログラマーです。
私は持っていませんが、インターネット上の他の人は持っています。
米国海軍向けの並列音響線追跡アルゴリズムの実装におけるC++とErlangの相対的なメリットを調査しました。 pthreadベースのC++プログラミングよりも、並列Erlangの方がはるかに小さい学習曲線と優れたデバッグ環境が見つかりました。 C++の実装は、Erlangプログラムよりも少なくとも12倍優れていました。 IBM Cell BEマイクロプロセッサでErlangを使用しようとすると、Erlangのメモリフットプリントにイライラしました。 （ソース）
そして、私の心に近い何か、私はICFPコンテストの余波で読み返したことを覚えています。
コーディングは非常に簡単で、疑似コードをC++に変換しました。 JavaまたはC＃を使用できたかもしれませんが、C++での高レベルのプログラミングも同じくらい簡単になり、すぐにいくつかにドロップダウンするオプションを保持したかったのです。 Erlangは、ハッキングに使う他のお気に入りの言語ですが、パフォーマンスの問題が発生するのではないかと心配していました （ソース）
私にとって、Erlangが動的に入力されるという事実は、私を警戒させるものです。私はdoが動的に型付けされた言語を使用していますが、それはそれらのいくつかが非常に問題指向であるためです（Pythonを使い、Pythonで多くの問題を解決します）。
とは言うものの、実際にはしばらくの間、Erlangを試してみるつもりでしたが、ソースのダウンロードを開始しました。結局、あなたの「質問」は何かを達成しました。 ;-)
いくつかの理由：
Cファミリーの言語に慣れている人なら誰にでも見えないから
Java Virtual Machineで実行できるようにしたかったので、（JConsoleのような）私が知っていて理解していたツールと、JITとGCに費やした長年の努力を活用できます。
何年もかけて構築してきたすべての（Java）ライブラリを書き直す必要はなかったからです。
私はErlangの「エコシステム」（データベースへのアクセス、設定、ビルドなど）について何も知らないからです。
基本的に、私はJava、そのプラットフォーム、およびエコシステムに精通しており、JVM上で実行されるものの構築に多大な努力を費やしました。スカラに移動するのははるかに簡単でした
単一のマルチプロセッサシステム上で多くの共有データを使用して実行するプロジェクトでErlangを使用することを決定し、Clojureが実際に共有メモリの同時実行性を得るため、Clojureを使用しました。分散データストレージシステムに取り組んだとき、Erlangは分散メッセージパッシングシステムに本当に輝いていたため、Erlangはぴったりでした。 プロジェクトを言語の最高の機能と比較し、それに応じて選択します
私は大学以来Erlangを知っていますが、これまで自分のプロジェクトでErlangを使用したことはありません。主にデスクトップアプリケーションを開発しているため、ErlangはNice GUIを作成するのに適した言語ではありません。しかし、すぐにサーバーアプリケーションを実装し、Erlangを試してみることにします。しかし、私はもっとライブラリが必要だと心配しているので、代わりにJavaを試してみます。
独自の多層、バイナリプロトコルのメッセージゲートウェイに使用します。サーバーのOTPパターンとサービス間の関係、およびバイナリパターンマッチングにより、開発プロセスが非常に簡単になりました。このようなユースケースでは、おそらく他の言語よりもアーランを好むでしょう。
JVMはツールではなく、プラットフォームです。私は仕事に最適なツールを選択することに賛成していますが、プラットフォームはほとんど決まっています。ゼロから、既存のコード/ライブラリを再利用したくないという独立したものを開発している場合を除き（既に孤立している可能性の低い3つの側面）、プラットフォームを自由に選択できます。
複数のツールと言語を使用していますが、主にJVMプラットフォームをターゲットにしています。それは私のプロジェクトのすべてではないにしても、ほとんどの場合、Erlangを排除します。その概念のいくつかと同じくらい興味深いものです。
シルビオ
ErlangランタイムとOTPプラットフォームの多くの設計面が好きでしたが、開発するのにかなり面倒なプログラム言語であることがわかりました。 1行変更するだけのコード。また、RubyまたはClojureで簡単な一部の操作は、文字列処理など、Erlangでは面倒です。
共有データベースに依存する分散システムの場合、Mnesiaシステムは非常に強力で、おそらく良いオプションですが、学習して楽しみを持つために言語でプログラムします。銀行口座のチュートリアルとXMPPサーバーのプラグインの作成を開始しました。
私は並行性の観点からErlangが大好きです。 Erlangは本当に並行性を正しく実現しました。主に構文のためにアーランを使用することになりませんでした。
私は貿易で機能的なプログラマーではありません。私は通常C++を使用しているため、スタイル（OOP、命令型、メタなど）を切り替える能力を切望しています。アーランは私に不変データの神聖な牛を崇拝するように強制しているように感じました。
並行性、シンプル、美しい、スケーラブル、強力なアプローチです。しかし、私がErlangでプログラミングをしている間ずっと、私はスレッド間のデータ共有を許可せず、Erlangの同時実行モデルを使用したJavaのサブセットを好むだろう。私はJavaは、Erlangのプロセスおよびチャネルと互換性のある機能セットの言語を制限する最善策です。
つい最近、私は Dプログラミング言語 が Erlangスタイルの並行性 を使い慣れたcスタイルの構文とマルチパラダイム言語で提供することを発見しました。私はまだDと大規模な同時実行を試みたことはないので、完璧な翻訳かどうかは言えません。
専門的にはC++を使用していますが、Erlangの場合と同様に、大規模な同時実行アプリケーションをモデル化するために最善を尽くしています。ある時点で、Dの同時実行性ツールに実際のテストドライブを提供したいと思います。
私はアーランを見ることもしません。
次の2つのブログ投稿が私を釘付けにしました。
Erlangの機械はリスト全体を処理して、処理するメッセージがあるかどうかを判断します。メッセージを取得する唯一の方法は、リスト全体を処理することです（pidによるメッセージのフィルター処理には、メッセージリスト全体の処理も含まれると思います）
http://www.lshift.net/blog/2010/02/28/memory-matters-even-in-erlang
奇跡はありません。実際、Erlangは避けられない過負荷に対処するためのサービスをあまり多く提供していません。メッセージキュー内の使用可能なスペースのチェックを処理するのはアプリケーションプログラマーに任されています（キューを歩いて現在の長さを把握することと、送信者間の公平性を確保するための組み込みのメカニズムがないと仮定します）。
（1）と（2）の両方が私の本の素朴さをはるかに下回っており、Erlangの機械の中に同様の性質のソフトウェア「宝石」がもっとあると確信しています。
だから、私にはアーランはありません。
過負荷状態で高いパフォーマンスを必要とする大規模なシステムに対処しなければならない場合、C++ + Boostはまだ町で唯一のゲームです。
次にDを見ていきます。
Erlangをプロジェクトに使用したかったのは、CPUの数が多いと驚くほどのスケーラビリティがあるためです。 （他の言語を使用し、時々壁にぶつかって、アプリを微調整する必要があります）
問題は、アプリケーションを複数のプラットフォーム（Linux、Solaris、AIX）で提供する必要があることでした。残念ながら、現時点ではAIXのErlangインストールはありません。
小規模な操作であるため、ErlangのAIXバージョンを移植および保守する手間が省け、アプリケーションの一部にLinuxを使用するように顧客に依頼するのは簡単です。
AIX Erlangが使用できるように到着することを期待しています。