ElixirにPythonを組み込むのは、問題ありません

• ここ数年、Elixirは Nx (Numerical Elixir) プロジェクトを通じて、機械学習とデータ分野での能力を拡張してきた
• Nx、Explorer、Axon、Bumblebee、Scholar などのプロジェクトが登場し、Python や R のエコシステムで得られた教訓をもとに発展している
• 当初は Python ライブラリに直接依存しない方針を採っていたが、それは Elixir に最適化された設計を追求し、Python 環境設定の複雑さを避けるためだった
• ところが、最近この分野で Elixir 導入 を主導しているのは Livebook である
  • Elixir と Erlang の強みを基盤 に、再現性、分散実行、アプリ開発の最前線にあるノートブックプラットフォーム
  • Livebook を通じて Elixir エコシステムに初めて足を踏み入れようとするチームや企業の関心が、ますます高まっている
• しかし障害もある
  • Elixir と Livebook をインフラに導入しようとする企業の多くは、すでに Python ベースのワークフロー、パッケージ、リポジトリを利用している
  • これは、この選択のために Elixir で同等のパッケージを探すか最初から書き直す必要があることを意味し、データスタックに Elixir を追加する際のリスクとコストを高めることになる
• これを解決するために、Erlang VM 内に Python インタプリタを組み込む Pythonx を発表した

Pythonx

• Pythonx は、Elixir と Python 間の自動データ変換、コード評価、仮想環境管理機能を提供する
• Optical Character Recognition（OCR）を実行するために pytesseract パッケージを利用できる
• req を使って画像をダウンロードした後、Pythonx.uv_init/1 を呼び出して Python と依存関係をダウンロードして初期化する
• Pythonx.eval/2 を使って Python コードを実行し、その結果を Elixir の文字列に変換する

内部構造

• Python の CPython 参照実装は、他のアプリケーションに組み込むことができる
• Python インタプリタの中核機能は C ライブラリとして提供されている
• C/C++ アプリケーションはそのライブラリをリンクし、API を使ってコードを実行したりオブジェクトと相互作用したりできる
• Elixir は Erlang NIFs を通じて C/C++ との相互運用性を提供する
• Pythonx は NIFs を活用して Python を組み込み、同一の OS プロセスで動作する
• Python と Elixir の間のデータ受け渡しは効率的に行われる

Livebook の多言語サポート

• Pythonx をベースに、Livebook での Python サポート追加が進められている
• 同じノートブック内で Elixir と Python が相互にやり取りできるようになる
• Livebook は Python と依存関係を自動でインストールし、Elixir と Python の変数間の変換を管理する
• 再現可能な環境を保証する
• 現在はコード補完やドキュメント化などの追加作業が進められており、Livebook nightly をダウンロードして利用できる

利用時の考慮事項と代替手段

• Pythonx の主な目的は、Livebook やスクリプト内で Python ワークフローを統合することにある
• Python のグローバルインタプリタロック（GIL）により、複数の Elixir プロセスから Pythonx を呼び出す場合に並行性が制限される可能性がある
• 単一の Elixir プロセスから呼び出すか、Python ライブラリが同時呼び出しを処理できるかを確認する必要がある
• 代替として、System.cmd/3 または Port を使って複数の Python プロセスを管理できる
• AI ワークフローでは、Bumblebee を通じて事前学習済みモデルを実行できる
• Ortex を活用して ONNX モデルを実行できる
• LLM については、サードパーティ API を使うか、オンプレミスで Llama.cpp の Docker コンテナを実行できる
• HTTP ベースのインターフェースを使う場合は、Elixir の Instructor や LangChain などのツールを活用できる

Fine プロジェクト

• Pythonx は NIFs を使って実装されている
• NIFs は C で実装された Elixir 関数であり、多くのボイラープレートコードを必要とする
• メモリ管理やエラー処理には複雑さがある
• これを解決するため、C++ ベースの Fine ライブラリが開発された
• Fine はデータ構造変換の自動処理、リソースオブジェクトの安全な管理、例外発生機能を提供する
• NIF 作成時のコード量を大幅に減らすことができる

結論

• Numerical Elixir プロジェクトの目標は、Elixir がデータおよび機械学習エコシステムの中で独自のアイデンティティを持つようにすることにある
• 現在は相互運用性を主要な目標としている
• Pythonx は Elixir に Python を組み込み、両言語間の透過的な相互変換を可能にする

[aer0700]

NumPyは本当に最高です…

[GN⁺]

Hacker Newsの意見

• Livebook の機能は非常にすばらしい。Elixir から C++ NIFs を通じて CPython を直接呼び出し、Elixir ネイティブのデータ構造を返す点がクリーン

  • 本番サーバーでは Pythonx の使用はやや危険かもしれない。Elixir アプリと同じ OS プロセス内で実行されるため、Elixir/BEAM アプリの強力な障害復旧機能を迂回してしまう
  • 一般に Elixir アプリには、自身の BEAM プロセスの失敗を優雅に処理できる監督ツリーがあり、これは Elixir、Erlang、Gleam のような言語の大きな利点
  • NIFs を使う場合、Pythonx で未処理の例外が発生すると、OS プロセス全体とすべての BEAM プロセスを停止させる可能性がある
  • Rustler は Elixir における Rust 用の人気 NIF ラッパーで、NIFs が非常に有用な場合もあるが、アプリ全体を停止させうるリスクを考慮すべき
  • Python や Rust のような他のネイティブコードを Ports を使って実行するほうが、この点ではリスクが低い

• Elixir コミュニティの「よく知られた」人たちがこのアプローチを支持し、積極的に開発しているのを見るのは良いこと

  • VM とランタイムは異なる言語や技術を調整するのに非常に適していて、標準トラックとオフロードトラックがあるように感じられる
  • オフロードという「危険そうに見える」アイデアと安全な実行の違いは、多くの場合単に作業量だけだが、ランタイムはそれを後押ししている
  • NIF であるため多少のリスクはあるが、別の BEAM インスタンスを立ち上げて、それを通じて分散させることもできる

• NIFs 使用の安全性の問題を指摘した別のコメントもある

  • Erlang VM スケジューラは NIF をプリエンプトできないため、長時間実行される Python 呼び出しが VM を停止させる危険がある
  • GIL は Python の同時実行を妨げるが、Erlang の呼び出し側は複数の Python インタープリタを実行できるため、Ports では問題にならない

• とても有益な記事。Pythonx が単なるサブプロセス呼び出しではなく、同一プロセス内で動作することを明確に書いているのが良い

  • Elixir から Python で定義された関数を呼び出す例も追加されていればよかった

• Elixir が AI 戦争において JavaScript や Python より適しているにもかかわらず、出遅れているのを見るのはうれしい

  • Elixir の ML 基盤を最初から拡張しようとした初期の判断は好きだが、急速に進化する Python ライブラリを活用できる道ができたのも良い

• Python から Elixir/Erlang エコシステムへ入るのは難しすぎると感じていたが、Pythonx によって段階的な学習がずっと現実的に見える

  • Python の GIL 問題について、自由スレッディングを試したのか気になる

• Elixir には、Python にもあってほしい機能がいくつかある

  • アトム、ほとんどのものがマクロであること、パイプ |>、真の不変性、監督ツリーによる真の並列性と並行性、ホットコードリロード、耐障害性

• Elixir に深く関わり、Python を多用してきた人間として、非常に実用的だと思う

  • C++ NIFs を簡単に作れる Fine ライブラリのほうにさらに興味がある

• このプロジェクトとブログ記事は、自分のために作られたかのように感じる。試してみたい、ありがとう