「ジュリア」科学計算言語プロジェクトはどれくらい成熟していますか？

現在使用しているC ++およびPythonの（部分的な）代替として、数値/シミュレーションモデリングプロジェクトに使用する新しい言語の学習を検討しています。ジュリアに出会いました。それが主張するすべてを行うと、高レベルの科学計算ライブラリコード（PyPlotを含む）にアクセスでき、Cと同様の速度でforループを実行できるため、すべてのプロジェクトでC ++ と Pythonの両方を置き換えることができます。また、他の言語のいずれにも存在しない適切なコルーチンのようなものからも恩恵を受けるでしょう。

しかし、それは比較的新しいプロジェクトであり、現在バージョン0.xであり、日々使用する準備が整っていないというさまざまな警告（過去のさまざまな日付に投稿されています）が見つかりました。したがって、この段階でこの言語を学ぶために時間をかけることを個人的に検討する必要があるかどうかを評価するために、プロジェクトのステータスに関する情報（2014年2月、または回答が投稿されるたび）が欲しいです。

Juliaプロジェクトに関する特定の関連する事実に焦点を当てた回答をいただければ幸いです。他のプロジェクトでの経験に基づく意見にはあまり興味がありません。

特に、Geoff Oxberryのコメントは、Julia APIがまだ流動的であり、コードが変更されたときに更新する必要があることを示唆しています。APIのどの領域が安定しており、どの領域が変更される可能性があるのか​​、これがどの程度であるかを知りたいと思います。

私は通常、線形代数（固有問題の解決など）、多くの変数を含むODEの数値積分、PyPlotおよび/またはOpenGLを使用したプロット、および低レベルCスタイルの数値計算（たとえば、モンテカルロシミュレーション） ）。ジュリアのライブラリシステムは、これらの分野で完全に開発されていますか？特に、APIはこれらのタイプのアクティビティに対して多かれ少なかれ安定していますか、それともJuliaの新しいバージョンにアップグレードした後、私の古いコードが壊れる傾向があると思いますか？

最後に、現在ジュリアを深刻な仕事に使用するかどうかを決定する際に検討する価値がある他の問題はありますか？

ジュリアは、この時点で（2019年5月、ジュリアv1.1とv1.2がリリースされようとしています）、科学計算用に非常に成熟しています。v1.0リリースは、毎年のコード破損の終わりを意味します。それにより、多くの科学計算ライブラリは、中断することなく単純に成長する時間を持っていました。Juliaパッケージの概要は、pkg.julialang.orgで確認できます。

コア科学計算のため、DifferentialEquations.jlの微分方程式（常微分方程式、のSDE、微分代数方程式、のDDE、ギレスピーシミュレーション、等）のためのライブラリFlux.jlニューラルネットワークのための、及びジャンプ数理計画（最適化のためのライブラリ：線形、二次、混合整数などのプログラミング）は、科学コンピューティングエコシステムの基盤の3つです。特に微分方程式ライブラリは、他の言語で見られるものよりもはるかに開発されており、EPIRK積分器、Runge-Kutta-Nystrom、Stiff / Differential-Algebraic遅延微分方程式、および適応時間スティッフな確率微分方程式インテグレーター、および随伴感度分析、化学反応DSL、マトリックスなしのニュートンクリロフ、完全な（データ転送なしの）GPU互換性など、ニューラル微分方程式のトレーニングなど、その他すべての機能素晴らしいベンチマーク結果（免責事項：私は開発主任です）。

成熟したJuliaエコシステムについて少し気が遠くなるのは、その構成可能性です。基本的に、誰かがDifferentialEquations.jlのような汎用ライブラリ関数を構築するとき、AbstractArray / Number型を使用して、その場で新しいコードを生成できます。たとえば、エラー伝播用のライブラリ（Measurements.jl）があり、それをODEソルバーに貼り付けると、パラメーターサンプリングなしでエラー伝播を行う ODEソルバーの新しいバージョンが自動的にコンパイルされます。このため、機能のコード自体が生成されるため、一部の機能が文書化されていない場合があります。そのため、ライブラリの構成についてさらに検討する必要があります。

合成が最も役立つ方法の1つは線形代数です。たとえば、ODEソルバーを指定するとjac_prototype、内部で使用されるヤコビアンの型を指定できます。もちろんで物事をありますLineraAlgebra標準ライブラリのようにSymmetricしてTridiagonal、あなたはタイプ汎用アルゴリズムで組み合わせの柔軟性の有用性、人々は今では消え、全体の配列型のライブラリを構築している与えられ、ここで使用することができますが。BandedMatrices.jlおよびBlockBandedMatrices.jlはlu、高速な過負荷を持つバンド化マトリックスタイプを定義（ブロック）するライブラリであり、偏微分方程式のシステムのスティッフなMOL離散化の解決を加速する優れた方法になります。PDMats.jl正定値行列を指定できます。Elemental.jlでは、分散スパースヤコビアンを定義できます。CuArrays.jlはGPUで配列を定義します。等。

次に、すべての番号タイプがあります。Unitful.jlはコンパイル時にユニットチェックを行うため、オーバーヘッドのないユニットライブラリになります。DoubleFloats.jlは、Quadmath.jlおよびArbFloats.jlとともに、高速で高精度のライブラリです。ForwardDiff.jlは、デュアルナンバー演算を使用するフォワードモード自動微分のライブラリです。そして、私はこれらをリストし続けることができます。はい、DifferentialEquations.jlのような十分に汎用的なJuliaライブラリにそれらをスローして、これらの数値型に特に最適化されたバージョンをコンパイルできます。ApproxFun.jlのようなものでもこれは、代数オブジェクト（Chebfunなど）としての関数であり、この一般的なシステムで機能し、関数空間のスカラーのODEとしてPDEを指定できます。

汎用性の利点と、ジェネリックジュリア関数で新しい効率的なコードを生成するために型を使用できる方法を考えると、コアサイエンスコンピューティング機能の実装をピュアジュリアに組み込むには多くの作業がありました。Optim.jl非線形最適化のために、NLsolve.jl、非線形システムを解くためのIterativeSolvers.jlを線形システムと固有システムの反復ソルバーのために、BlackBoxOptim.jlなどブラックボックスの最適化のための、でもニューラルネットワークライブラリFlux.jlはちょうどCuArraysを使用しています。 jlのGPU機能のためのGPUへのコードの自動コンパイル。この構成性は、DiffEqFlux.jlの神経微分方程式のようなものを作成したものの中核でした。Turing.jlのような確率的プログラミング言語も非常に成熟しており、同じ基礎となるツールを使用しています。

Juliaのライブラリは基本的にコード生成ツールに基づいているため、コード生成に関するツールがたくさんあることは驚くべきことではありません。ジュリアのブロードキャストシステムは、上記の多くの機能を提供するために配列タイプによってオーバーロードされる融合カーネルをその場で生成します。CUDAnative.jlを使用すると、JuliaコードをGPUカーネルにコンパイルできます。ModelingToolkit.jlは、ASTを数学的なコードを変換するためのシンボリックシステムに自動的に脱糖します。Cassette.jlルールを使用して、コンパイル時間前に関数を変更する（たとえば、すべての配列割り当てを静的配列割り当てに変更し、操作をGPUに移動する）ことにより、他の誰かの既存の関数を「オーバーダブ」できます。これはより高度なツールです（科学計算を行うすべての人がコンパイラを直接制御することは期待していません）が、これは次世代ツールの多くがどのように構築されているかということです（むしろ、機能がどのように自分自身を書いているか）。

並列処理については、GPUについて説明しましたが、ジュリアには組み込みのマルチスレッドと分散コンピューティングがあります。ジュリアのマルチスレッドは、ネストされたマルチスレッドの自動スケジューリングを可能にする並列タスクランタイム（PARTR）アーキテクチャをすぐに使用します。MPIを使用する場合は、MPI.jlを使用できます。そしてもちろん、それをすべて利用する最も簡単な方法は、AbstractArrayタイプのセットアップを使用して、その操作で並列処理を使用することです。

ジュリアには、科学アプリケーションに使用される汎用言語に期待される基本的な基礎となるエコシステムもあります。それはしていジュノIDEでブレークポイントと内蔵のデバッガは、それが持っているPlots.jlをプロットのすべての種類を作るため。Revise.jlがファイルを保存するときに関数/ライブラリを自動的に更新するなど、多くの特定のツールも優れています。DataFrames.jl、統計ライブラリなどがあります。最も素晴らしいライブラリの1つは、実際にはDistributions.jlです。これにより、ディストリビューションに一般的なアルゴリズムを記述できます（例：rand(dist)渡された分布の乱数を取得します）、一変量および多変量分布の負荷があります（そしてもちろん、ディスパッチはコンパイル時に発生し、これは分布に固有の関数をハードコーディングするのと同じくらい速くなります）。名前を付けたデータ処理ツール、Webサーバーなどがたくさんあります。この時点で十分に成熟しており、基本的な科学的なものがあり、それが存在することを期待している場合は、.jlまたはJuliaでそれをGoogleに表示するだけです。

次に、地平線上で心に留めておくべきことがいくつかあります。PackageCompilerは、Juliaライブラリからバイナリをビルドすることを検討しており、すでにいくつかの成功を収めていますが、さらなる開発が必要です。Makie.jlは、インタラクティブ機能を備えたGPUアクセラレーションプロット用のライブラリ全体であり、さらに作業が必要ですが、ジュリアのメインプロットライブラリになることを本当に望んでいます。Zygote.jlは、ソースベースの自動差別化ライブラリであり、トレースベースのAD（Fluxのトラッカー、PyTorch、Jax）のパフォーマンスの問題はなく、すべての純粋なJuliaコードで機能することを目指しています。等。

結論として、あなたは多くの場所で多くの動きを見つけることができますが、ほとんどの分野ですでにしっかりした成熟したライブラリがあります。「採用されるのか」と尋ねる場所ではなくなりました：ジュリアは、十分な人々（何百万ものダウンロード）によって採用されており、永久に留まる勢いがあります。とてもいいコミュニティがあるので、風を吹いて並列計算や数値微分方程式について話したいだけなら、そのための最高のチャットルームのいくつかはJulialang Slackにあります。それがあなたが学ぶべき言語であるかどうかは個人的な質問であり、あなたのプロジェクトにとって適切な言語であるかどうかは技術的な質問であり、それらは異なっています。しかし、それは成熟した言語であり、開発者の大規模で一貫したグループの支援を受けていますか？それは肯定的なイエスのようです。

そうでない場合、再度検討する前にどれくらいの時間待つべきかについて、おおよその大きさの推定値を与えることは可能ですか？

計算科学言語が成熟するのにかかる時間の大まかな概算の見積もりは、約10年です。

例1：SciPyは2001年頃に開始されました。2009年に、Scipy 0.7.0がリリースされ、ODEインテグレーターにはVODEへのインターフェイスがありました（これはに相当しode15sます; ode15sNDFベースで、VODEはBDF / Adams-Bashforthに依存します）。SciPy 0.10.0では、dopri5MATLABにほぼ相当するのインターフェイスであり、ode45通常、大学生に最初の実用的な数値積分法として導入されたRunge-Kutta 4次法です。SciPy 0.10.0は2011年12月にリリースされ、私が知っているすべてのエンジニアリング学部生に導入されたMATLABの機能を含めるのに約10年かかりました。

例2：Mathworksは1984年に設立されました。最初のリリースでは、JACKPACという名前のCへのLAPACKポートを使用しました（Jack Littleを書いたMathWorksエンジニアの後）。2000年までLAPACKに置き換えませんでした。

ジュリアは時間がかからないかもしれませんが、私は設立から主流になるまで約10年を見積もっています。（もう1年かそこらでした;多分9-10年ですか？）

ジュリアのライブラリシステムは、これらの分野で完全に開発されていますか？特に、APIはこれらのタイプのアクティビティに対して多かれ少なかれ安定していますか、それともJuliaの新しいバージョンにアップグレードした後、私の古いコードが壊れる傾向があると思いますか？

私はジュリアを使用していないので、ジェフ・ベザンソンがジュリアについてのプレゼンテーションをするのを見ただけなので、私が言うことを一言で言ってください。C、Python、Fortranのライブラリを簡単にリンクして使用できるように、後ろ向きに曲がりました。目的の処理を行うJuliaライブラリが見つからない場合は、より確立された言語でライブラリのJuliaシムを作成します。その結果、私は図書館の不足が心配になるとは思わない。懸念は、コア言語機能への変更がお尻に噛みつかないようにすることだと思います。Julia Gitリポジトリのマイルストーンを見ると、「breaking」タグがかなり使用されていることがわかります（0.2リリースでは12回、0.3リリースでは5回）。私にとって、それはコア言語がまだ進化していることを示唆しているので、私は今この言語を使うのをためらっています。

編集：アウレリウスは良い点をもたらします：

ジュリアが実際に主流になり、他の多くの言語のように不明瞭に死ぬだけではないことを、あなたはどう思いますか？SciPy / numpyには、成長を続けるpythonコミュニティの支援がありましたが、Juliaにはありません。

元の答えでは、「ジュリアは主流になりますか？」という質問を避けることにしました。できるだけ。失敗は簡単です。成功は難しいです。Juliaの最良の比較は、MATLAB、R、Octaveなどの技術計算言語と比較することだと思います。HPC言語（Chapel、Fortress、UPCなど）は、テクニカルコンピューティング言語よりも対象範囲が狭く、汎用言語（C、Python、C ++など）は、テクニカルコンピューティング言語よりも対象範囲が広くなっています。

ジュリアに役立つと思うのは、表現力を犠牲にすることなくパフォーマンスを設計することです。Juliaは、MATLAB、R、さらにはPythonよりも、Cなどのコンパイルされた言語との競争力がはるかに優れています。この設計目標は、次のような既存の言語から人々を引き付けることができる機能でもあります。

• パフォーマンスを重視し、CやFortranなどの言語を使用しているが、コンパイルされた言語からインタープリター言語の数行を減らすために、わずかなパフォーマンス（2倍程度）を犠牲にしたい人より迅速な開発とテスト）。
• 高い生産性を重視し、Python、R、MATLABなどの言語を使用しているが、より高いパフォーマンスが必要な人。実行に関して言えば、純粋なPython、純粋なMATLAB、および純粋なRは遅いです。これらの言語の開発者は、コンパイルされた言語でライブラリをラップする方法を失いましたが、すべてをラップすることはできません。また、ある時点で、コア言語の速度が遅くなります。Core Juliaはより高速で、より多くの科学をより速く行うことができます。
• フリーソフトウェアを気にする人。Juliaは解釈されており、無料です（Python、Octaveなども同様です）。MATLABはそうではありません。

また、ジュリアは並列処理を促進しようとしています。私はその点を拡大するほどひどく資格があるとは思いませんし、それが言語の主な魅力だとは思いませんが、彼らが取り組んでいるセールスポイントだと思います。

ただし、技術的なメリットがあったとしても、言語の作成者は、言語を広め、伝道するために足を踏み入れなければなりません。ジェフ・ベザンソン、アラン・エーデルマン、スティーブン・カルピンスキー、およびビラル・シャーは、言語を成功させるために一生懸命働いています。アラン・エーデルマンは計算科学コミュニティと深いつながりがあり、以前は言語レベルのプロジェクト（特に、MATLABのStar-P拡張）に取り組んできました。ジェフ・ベザンソンは、しばらくの間、ジュリアを計算科学者や技術者に紹介するために会議のサーキットを行ってきました。MITでは、学生とスタッフ（特にSteven G. Johnson）を募集して、Juliaにライブラリを追加することで貢献するという良い仕事をしてきました。Wiredに記事があり、わずか1年後にはWikipediaの記事を自分で入手することができました。Gitリポジトリには、数千の星、数百のフォーク、そして何百もの時計がありますので、オープンソースの基準により、彼らのプロジェクトは成功しています。これまでのところ、彼らはすべて正しいことをしてきたと思うので、それはその努力を維持し、コミュニティを構築することの問題です。彼らはまだ失敗する可能性がありますが、ここまで到達することは、成功する合理的なチャンスがあることを示唆しています。

ジュリアは学ぶ価値があると思います。私はそれを使用して、いくつかの研究有限要素コードを作成し、非常に迅速に作成しました。私は自分の経験にとても満足しています。

ジュリアは、他の言語では達成が難しいとわかったワークフローを有効にしてくれました。MATLABのようなプロトタイピング言語として使用できますが、動作するコードがあり、それを高速化するためにプロファイリングの繰り返しを行っている場合、MATLABとは異なり、ホットスポットをCコードで置き換えるのは簡単です。彼らは、C（およびPython）とのインターフェースを設計上の優先事項にしています。

したがって、この言語により、数学的な定式化から機能的なコードへ、そして機能的なコードから高性能なコードへと非常に迅速に移行することができました。ジュリアのこの機能は売れ行きが悪いと思いますが、非常に大きな価値があります。

多くの場合、機能的な有限要素コードを作成してから数時間で、Cのパフォーマンスを（自分のCコードと比較して）取得しています。これまでのところ、Juliaの機能のみを使用する場合、通常Cの3倍以内に到達します。この後、ホットスポットをC関数に置き換えます（Juliaにはこれらを識別するためのスタックサンプリングプロファイラーが付属しています）。多くの場合、Juliaがマーシャリングを処理して、問題のあるホットスポットのコード行を「ccall」に置き換えるだけで済みます。

ジュリアが今欠けている主なものは、より大きなプロジェクトのためにそれを検討することをheしていると思いますが、完全にサポートされているデバッガーの欠如とプロットの貧弱なサポートです頻繁に休憩していたこと）。コードに関する即時のフィードバックは非常に重要です。また、インタラクティブなデバッグなしで生き残る方法もわかりません。この点で、MATLABとGDBに非常に甘やかされています。

私の経験から、ジュリアはまだ（科学的な）日常的な使用の準備ができていません（2016年3月の安定化バージョン0.4について話している）。言語自体は素晴らしく、機能が豊富で一貫しています。matlabとpythonの両方からのさわやかな一歩です。確かに、この初期段階でもJuliaが適切な選択である場合があります。しかし、信頼できる成熟した科学ライブラリが必要な場合は、今すぐ移行することはお勧めできません。私が遭遇した主な問題は次のとおりです。

• Juliaのコア外のパッケージは信頼できません。それらは、更新で壊れ、変更され、置き換えられ、時には不完全であるか、単に壊れています。
• Juliaの並列処理機能（最も有望なmatlabのキラー機能）は未熟です。セグメンテーションフォールト、メモリリーク、クラッシュ、期待外れのパフォーマンスが発生します。時々、それらはジュリアの他の部分、例えば線形システム用のソルバーやコア外のパッケージとうまく機能しないことがあります。これらの機能は有望に思えますが、私にとってはしばしば十分に機能しません。@parallel理論的には、forループの前に単純に記述するだけでは十分ではありませんでした。
• 多くのささいなこと、小さなバグと一緒に暮らすことができます：あまり良くない、時々誤った呼び出しスタックトレース、少しバグのあるインタープリター履歴、パッケージの読み込みが遅い、1つまたは別のパッケージ/関数のパフォーマンスが悪いなど。ほとんどがmatplotlibのラッパーであるPyPlotパッケージであり、現在のところそれに代わるものはありません。それがそこにあることは本当に素晴らしいことであり、それはほとんど動作します。ただし、データをプロットする必要がある場合は、非常に遅いパフォーマンスと問題に備えてください。

これはすべて良くなります。いつかジュリアはほぼすべての面でmatlabやpythonよりも優れていると確信しています。革新的なパッケージが開発される可能性は非常に高いです。すでに大きなコミュニティがあるようです。現在でも、openclからWebサーバーに至るまでのユースケースを備えた豊富なパッケージがあります。pythonまたはcライブラリの使用は非常に簡単なので、ライブラリの可用性という点でおそらく壁にぶつかることはないでしょう。ジュリアの大きな強みは、さまざまなソースからの高性能な機能を現代的で一貫性のある高レベル言語でつなぎ合わせることのできる楽さです（上記の回答を参照）。しかし、全体としては、生産的に使用するのに十分なほど成熟しておらず、安定していないこともわかりました。