JuliaCon 2020に続いて、SGHワルシャワ経済大学のBogumił Kamiński教授は、言語とそのエコシステムの状況を要約し、Juliaはついにプロダクションレディになったと述べた。
Kamiński教授の記事は、いくつかの反応をHacker Newsで引き起こした。一部のコメント提供者は、特にドキュメント、パッケージ、ツール、およびサポートのために、Juliaが汎用言語としてプロダクションレディとみなすことができるのか疑っている。
InfoQは、Kamiński教授の立場をよりよく理解するために話して変更を加えた。
InfoQ: あなたの経歴とJuliaとの関わりについて教えていただけますか?
Kamiński氏: 私はポーランドのSGHワルシャワ経済大学の教授であり、オペレーションズリサーチとシミュレーションモデリングの分野でほとんどの研究を行っています。
私はコミット数でJulia言語への貢献者の上位5％にいます。特にDataFrames.jlのコアメンテナの一人としてJulia Dataエコシステムに大きく貢献しています。
StackOverflowで[julia]タグの2位の回答者としてランク付けされています。フルタイムのアカデミアに切り替わる前は、10年以上にわたって、ポーランドの最大の企業や機関向けにBI/DWH/データサイエンスプロジェクトをデプロイする数百人の開発者とアナリストのチームをマネージしていました。
InfoQ: あなたの記事の主な理由は、Juliaのエコシステムが成熟レベルに達し、プロダクションレディになったことだと思われます。この点についてさらに詳しく教えていただけますか? Juliaのプロダクション環境での採用を妨げたものと、それらの障害点を取り除いた最も重要な進歩は何でしょうか?
Kamiński氏: ここでは、Juliaがプロダクションレディであると私が理解していることを定義することが重要です。
私はそれを次のように定義します: 言語とコアパッケージが「6か月ごと」に大きな変化を起こさないレベルの安定性に到達すること。つまり、プロジェクトを開始して、長期 (数年間) 正しく機能するはずだと安全に期待できることです。
過去には、これは大きな問題でした。言語とコアパッケージは、APIを頻繁に変更する傾向がありました。1年前に作成されたチュートリアルは、常に更新などを取得しないと機能しませんでした。これは、言語とエコシステムが開発されていたときの自然な状態でした。さて、特にJulia言語のコアではこれらのことが大幅に変わったことがわかりますが、パッケージエコシステムでも同様のことが起こっていました。
これは、新しいパッケージがこの「不安定な」状態にないことを意味するものではありませんが、これはどのパッケージエコシステムでも見られるものです。新しいものは急速に進化するためです。たとえば、パッケージマネージャは本当に成熟していて、私は現在最高クラスの1つだと思います。
これが意味することは、特にバイナリ依存関係を持つパッケージの場合、物事を「正しく機能させる」ために多くの努力が払われてきたことです。それどころか、数年前にパッケージをインストールしようとして、一部の外部依存関係がコンパイルされなかったために失敗する可能性がありました。そのため、パッケージを実行するには、方法を知っている場合はそのパッケージのソースコードを手動で微調整する必要がありました。それはいつも明確ということではではありませんでした。
特に、Julia 1.5以降、Juliaのシームレスなエンタープライズデプロイメントが可能になりました。以前は、GitHubとの同期に使用されるパッケージマネージャプロトコルが原因で問題が発生しました。これは、企業環境のファイアウォール設定と頻繁に衝突していました。
なぜこれが関係するのでしょうか? さて、あなたは簡単にJuliaプロジェクトを「出荷」することができ、どんな環境の誰もがそれを比較的楽に実行できるはずだと期待することができます。もちろん、機能しない場合もあります。しかし、LinuxとWindows 10を使用した私の経験では、両方のプラットフォームで正しく機能します。
Juliaでプロジェクトを行う場合は、必要なことを実行するパッケージがあるか、C/Pythonで記述されたコードを簡単に使用して機能させることができることを期待します。私の投稿では、私たちがこの正確な状態にあることを強調したいと思いました。今週私が取り組んでいたことに基づく例として、Juliaにはグラフを操作するための優れた
LightGraphs.jlパッケージがありますが、私のコラボレーターはPythonを使用しており、igraphを使用することを好みます。これは、igraphを使用したサンプルコードです (Pythonのigraphのチュートリアルから採用):import igraph as ig g = ig.Graph() g.add_vertices(3) g.add_edges([(0,1), (1,2)]) g.add_edges([(2, 0)]) g.add_vertices(3) g.add_edges([(2, 3), (3, 4), (4, 5), (5, 3)]) g.pagerank()ここで、同等のJuliaコードだとどうなるかを尋ねます。ここにあります:
using PyCall ig = pyimport("igraph") g = ig.Graph() g.add_vertices(3) g.add_edges([(0,1), (1,2)]) g.add_edges([(2, 0)]) g.add_vertices(3) g.add_edges([(2, 3), (3, 4), (4, 5), (5, 3)]) g.pagerank()ご覧のとおり、同じです。もちろん、すべての場合ではありません。JuliaとPythonの辞書の構文は異なりますが、これは物事の仕組みに関する一般的な規則です。タブ補完があり、docstringに直接アクセスすることもできます。
これは実際にはどういう意味でしょうか? プロジェクトを行っている場合、「3か月後には、Juliaでまだ利用できないものがプロジェクトに必要になる可能性があるため、Juliaを使用できるだろうか?」 しかし、「現在、多くの汎用パッケージがすでに存在するため、比較的安全にJuliaを使用できます。何かが不足している場合でも、別の言語から使用するだけで、C/Python/R/...などにあれば、問題なく比較的簡単に使用できます」
また、プロダクションレディの一部として、
PackageCompiler.jlを使用すると、「Juliaをそのマシンにインストールしなくても、他のマシンで送信および実行できる実行可能ファイルを含むファイルのバンドルであるアプリ」を作成できます。私はそれをプロダクションレディの本質的な一部とは考えていません (プロダクションレディができていると考えられる多くのスクリプト言語はこのオプションを提供していません) が、多くのシナリオで機能があると便利です。ここで、「プロダクションレディ」の定義の一部として私が見ないものを明確にしましょう。Juliaはどのようなプロジェクトでも最適な言語だとは思いません。各プログラミング言語にはニッチがあり、Juliaのニッチはハイパフォーマンスコンピューティング/データサイエンスです (またはそれを呼んでいる) 。フットプリントが非常に小さいバイナリが必要な場合は、確かにJuliaは最適な言語ではありません。Android用のアプリを開発したいのなら、それも違います。
私が信じているのは、Juliaが適したプロジェクトを行いたい場合、プロダクションにしたい場合は、多くの一般的な要件を満たすニーズがある可能性が高いということです。これらの要件は、コア機能を、コードをデプロイするエコシステムの他の部分と適切に相互運用するために必要です。そして、Juliaは、既存のパッケージまたは外部ツールとの統合のいずれかを介して、これを簡単に達成できる成熟度レベルに達していると思います。これは、Juliaでは非常に簡単です。
InfoQ: あなたの主張は、特にJuliaを汎用言語としてプロダクションレディとみなすことにすると、Hacker Newsの一部のコメント投稿者には少し行き過ぎに聞こえました。これについていくつかのインサイトを追加していただけますか?
Kamiński氏: 投稿の冒頭に書いたことを引用すると
「私は20年を費やして、企業環境にデータサイエンス関連のプロジェクトをデプロイし (当時はデータサイエンスとは呼ばれていませんでしたが、予測を行うためにニューラルネットワークをトレーニングしていました)、エンタープライズソフトウェア開発に深く関わっている多くの同僚がいます。」
これは私の投稿のフレームです。つまり、データサイエンスを行っていますが、「バックヤード」や「学術研究所」ではなく、「ビジネス環境」で行っています。すでに上で説明したように、私も、おそらくJuliaに関係する開発者も、それがあらゆる種類の開発プロジェクトの「ワンストップショップ」であるとは主張していません。
Julia開発者調査のスライド28を見ると、人々がコンピューティングにJuliaを使用していることは明らかです。これらは、Juliaがプロダクションレディであると私が信じている分野です。
さて、ドキュメント、パッケージ、ツール、サポートなどについてですが。これは改善されるべきであり、改善されるはずです。そして私は、R/Python/Javaのようなより成熟したエコシステムが平均してここでより良いカバレッジを持っていることに同意します。たとえば、
DataFrames.jlのメンテナとして、最近のPRのほとんどはドキュメントに関連していると言えます。しかし、私はここのJuliaコミュニティを過小評価しません。一般に、質問があり、SO、Julia Discourse、またはJulia Slackに投稿した場合、通常は数分以内、多くても数時間以内に回答が得られると期待できます。これがこの種の本当の話です: 人々は通常非常に敏感で、バグは非常に迅速に修正されます。私がJuliaを一般的な開発者コミュニティ内でこの言語に熟練した十分な人々が利用できる主要な人材を挙げることができたら、プロダクトオーナー/プロジェクトマネージャーと、Juliaにコミットするとプロジェクトに取り組むのに十分な人を見つけることができないリスクがあるという彼らの気持ちを理解できます。しかし、ここで私は物事が急速に改善していると確信しています。前回のJuliaCon 2020には、20,000人を超える参加者がありました。また、無料のオンラインですでに利用可能なリソースが多くあります。
InfoQ: Juliaがプロダクションレディかどうか、またはどのドメインに対応しているかという質問の他に、この言語の主な強みは何だと思いますか? 少なくとも科学計算とデータサイエンスの分野では、Python、R、またはその他の言語の代わりになると思いますか?
Kamiński氏: ここでも、前回のJulia開発者調査のスライド8から11を引用するのが最善だと思います。スライド8の上位3つに焦点を当てます:
速さ - ここでは、状況は比較的単純です。パフォーマンスを必要とするTensorFlowやPyTorchなどの成熟したパッケージを取り上げます。これらは主にCで記述されています。また、PythonはCコアの単なる薄いラッパーです。次に、Flux.jlまたはKnet.jlを使用します。それらは本質的に純粋なJuliaで実装されています。そして、Juliaコードを書くと、たとえば それをGPUにコンパイルします。つまり、コードを高速に実行すると同時に、高級言語を利用する必要がある場合は、Juliaが自然な選択です。
使いやすさ - これには多くの側面がありますが、私の経験では、誰かがJuliaの原則を理解すると、数値計算を行うときのR/Python等の構文と設計の点で非常によく比較されます。この言語は、この種のタスクを適切にサポートすることを中心に設計されました。そして、それは構文だけでなく、物事が暗黙的に発生する場合や、明示的にする必要がある場合 (ブロードキャストなど) の選択でもあります。私の経験に基づくと、これによりJuliaコードの保守が容易になり、適切に記述されたコードは大部分が自己文書化されます。
コードはオープンソースで修正可能 - この側面には2つの側面があります。まず第一に、ほとんどのJuliaパッケージはMITライセンスです。これは、エンタープライズ環境では非常に歓迎されます。第二に、パッケージのほとんどは、何かがどのように機能するかが気に入らない場合はJuliaで書かれているので、自分で変更するだけです (そして、変更が必要なものがCで書かれている可能性が高いR/Pythonで行うよりもはるかに簡単です)。
JuliaをR/Pythonの代わりと見なすかどうかをよく聞かれます。そしてそれについての私の考えは次のとおりです:
パフォーマンスを必要とする複雑な計算を行っている場合は、プロジェクトのこれらの部分を開発するためのツールとしてJuliaを選択します。
パフォーマンスが重要でない新しいタスクがある場合は、最もよく知っている言語を使用してください (そして、上記のポイント1をたくさん実行する場合は、私と同じように、これにJuliaを安全に選択できます)。
レガシーR/Pythonコードがたくさんあり、それに満足している場合は、それに固執し、パフォーマンスが重要な部分が含まれている場合は、比較的簡単にJuliaで書き換えて、元のコードベースと統合できることを覚えておいてください (私はそのようなプロジェクトをたくさん行ってきました)。
InfoQ: Juliaの進化には何が見えますか?
Kamiński氏: まず、私はあなたの質問に暗示されていることに同意します。これは「革命」ではなく「進化」になります。Juliaのデザインは堅牢であることが証明されており、根本的に変わることはないと思います。むしろ、多くの分野で段階的な改善が見られるでしょう。
ここでいくつかの主要な特性に名前を付けるとすると、これらは次のようになります:
マルチスレッドサポートの改善。Juliaのコアユースケースに本当に関連していると思います。Juliaはすでにこれをサポートしていますが、それでも多くのことがこれで改善できます。同様に、GPU/TPU処理の改善が期待されます。
コンパイラの待ち時間の改善。繰り返しになりますが、リリースごとに改善されますが、これは誰もが認識していることであり、改善する必要があります。
より成熟したパッケージエコシステムを持つこと。ここでは、主にパッケージの品質、安定性、およびドキュメントを意味します。機能範囲に関しては、すでに何千ものパッケージが利用可能です。私が上で書いたことを強調するために、私は多くのコアパッケージがすでにかなり成熟していると信じていますが、私は物事がここで改善されるべきであるとコメントする人々に同意します。
コミュニティの成長。Juliaに興味を持っている人の数は大幅に増加していると思います。JuliaCon2020参加者の数によって。これは、a）将来、必要に応じて質の高いJulia開発者を採用することが容易になること、b）より多くの人々が問題を報告して関与することで、Juliaエコシステムの質に対する正のフィードバックループを作成することを意味する。繰り返しになりますが、DataFrames.jlのメンテナとして、私はこの変化を観察します。パッケージの開発の「コア」に一度も入ったことがない人々は、問題を開いたり、PRを行ったり、ソーシャルメディアで機能について話し合ったりします。
Juliaに興味がある場合は、JuliaCon 2020のすべての講演をYouTubeでご覧ください。