Juliaは動的言語を高速化することで二言語問題を終わらせた

科学技術計算は二言語ワークフローに落ち着いていた。研究者はPython、MATLAB、Rなどの動的言語でプロトタイピングと分析を行い、その後遅い部分をCやFortranで書き直していた。2020年のArs Technicaの特集記事とそのHacker Newsでの議論は、その継ぎ目のコストを明らかにした。スクリプト層では高性能を表現できず、高速層は書くのが苦痛で保守が難しい。

Juliaの賭けは、その継ぎ目を完全に取り除くことだった。そのコンパイラは型推論とLLVM上に構築されたJITを用いて、各関数を実際に呼び出される具体的な引数型に合わせてコンパイルするため、動的で数学的な言語がよく書かれたCに近い速度で動作できる。多重ディスパッチ——単一のレシーバではなくすべての引数型によってメソッドを選択すること——により、パッケージは互いの汎用関数を拡張できる。これが、独立したライブラリがそれぞれ独自のCコアをラップするのではなく、組み合わさる仕組みである。

2020年までに、この設計は単なるベンチマークではなく、実運用の成果を示していた。RelationalAIは自社のクラウド知識グラフデータベースが100% Juliaで書かれていると述べ、Pumasモデリングプラットフォームは製薬会社に出荷されFDA申請でも使用され、コメンテーターは微分方程式から数理最適化まで、Juliaライブラリが最高水準となったエコシステム全体を指摘した。バージョン1.5が最新であり、コア開発者たちは1.0以降に実質的な破壊的変更はなかったと主張した。

批判者たちにも言い分があった。最初のプロットの遅さと起動レイテンシ、未熟なツール群、そしてPythonに比べて実戦で鍛えられたライブラリが少ないことだ。擁護者たちは、Revise.jlを用いた反復開発と、単一の新しいメソッドで一つのホットスポットにパッチを当てられる能力により、同じコードが探索と本番の両方に役立つと答えた。まさにそれがこの設計の狙いだった。

動的言語自体をネイティブ速度にコンパイルする

型推論とJITの特化により、プログラマがホットパスのために方言を切り替えることなく、汎用的で表現力豊かなコードが高速になる。

多重ディスパッチにより、パッケージは他のパッケージの関数にメソッドを追加できるため、ODEソルバーや最適化などのエコシステムが互いのCコアを複製するのではなく組み合わさる。

科学者は問題を性能パラダイムに合わせて作り変えるのではなく、問題のメンタルモデルを保ち続けられ、書き直しに伴うバグの一類を丸ごと削減できる。

単一のコードベースが探索と本番の両方に役立つため、プロトタイプが実際に動作するシステムから乖離できない。

書き直しのステップをなくすには、二つの言語間により良い橋を架けるのではなく、表現層がそのまま本番層でもある単一の言語を構築せよ。

Ars Technicaの特集記事は2020年10月に掲載され、そのHacker Newsスレッドは284ポイントと212件のコメントを集め、Juliaの開発者自身も議論に加わった。設計の根拠はすでに2018年の論文「Julia: Dynamism and Performance Reconciled by Design」で著者らによってまとめられており、2020年のスレッドは研究用プロトタイプだけでなくRelationalAIや製薬モデリングでの導入を示していた。スレッドが挙げたトレードオフ——起動レイテンシ、ツールの成熟度、ライブラリの網羅性——は、エコシステムにとって引き続き残された課題であった。