- Chris LattnerはLLVMとSwift言語の中核開発者であり、最新のMLハードウェアの性能を最大限に活用するため、新しい言語Mojoを開発している
- Mojoは使いやすさとハードウェア詳細の制御を両立する言語設計を目指しており、型安全なメタプログラミングを活用してハードウェアの詳細を効率よく扱えるよう支援する
- GPU、TPU、ASICなどAIアクセラレータ生態系の分断問題を解決し、特定ベンダー依存を減らすための統合コンピューティングプラットフォームを構築することが中核的な背景にある
- 既存のGPUソフトウェアスタック（CUDA、ROCm、XLAなど）の互換性および複雑性の問題により、次世代の高性能かつ移植性の高い言語開発が不可欠である
- ModularはMojoを無料で提供し、統合ハードウェア対応やエンタープライズサービスなど、実際の問題解決に焦点を当てるビジネスモデルを推進している
Chris Lattner の紹介とキャリア
- Chris LattnerはLLVM、Clang、MLIR、Swift、Mojoなど、コンピューティング分野の複数の中核プロジェクトを率いてきた経験を持つ
- Apple、Tesla、Google、SiFive、Modularなど多様な組織で勤務し、コンパイラおよびプログラミング言語設計に関する幅広い実務経験を積んできた
- 初期にはBASICのような単純な言語とPC環境から出発し、ゲームやグラフィックスを通じてハードウェア性能の極大化に関心を持つようになった
- 大学時代、偶然にコンパイラ専攻の教授の影響を受け、システムと大規模ソフトウェア構造の魅力を感じた
コンパイラと言語設計のあいだを行き来して
- Chris Lattnerはコンパイラエンジニアリングと言語設計の両方を経験し、この2領域の接点で大きな成果を上げてきた
- たとえばLLVMは多様な言語が利用できる中間言語として、C++実装だけでなくRustやJuliaなど広範な適用事例を生み出した
- Swift開発も、既存のC++実装の限界と疲弊感を乗り越えようとする試みから始まり、パターンマッチングなどの実用的機能の必要性を重視した
- プログラミング言語の革新では、数学理論よりも実際の問題解決とユーティリティに基づいて設計するアプローチを好んでいる
プログラミング言語理論と実用性
- Chrisは数学的厳密さよりも問題解決中心の思考を重視し、PL論文でも理論そのものより実用的な例や活用事例に関心を持つ
- 数学的基盤の強い言語機能が一貫性と組み合わせやすさにおいて利点を持つことは認めつつ、実際の導入・採用は使用上の目に見える効用が原動力だと見る
- 新しい言語や技術は、**複雑さの「grain of sand」**をできる限り減らし、設計の単純化と拡張性を追求することが重要だと述べている
AIハードウェア生態系の構造的問題
- 伝統的なコンパイラインフラ（LLVM）はCPU中心だったが、AI/機械学習ではGPU、TPU、ASIC、FPGAなど多様な専用ハードウェアが求められる
- 各ベンダーが独自のソフトウェアスタック（CUDA、ROCm、XLAなど）を開発しており、これが互換性の欠如と生態系の分裂を招いている
- MLソフトウェア（例: PyTorchなど）はハードウェアベンダーごとに別個の最適化が必要で、保守や拡張がきわめて難しくなる問題がある
- ハードウェアごとにスタック、言語、ツール生態系が異なるため、ソフトウェア開発者の視点では生産性と移植性の低下が広く見られる
Modular と Mojo の役割
- Modularチームはこうした問題を解決するため、汎用的で統合的なソフトウェアプラットフォームの構築に注力している
- Mojoは最新GPUアーキテクチャ（Tensor Coreなど）の性能特化だけでなく、多様なハードウェアで移植可能なカーネル作成を目標に設計されている
- Mojo、MAX（高性能LLMサービングなど）、Mammoth（クラスター/Kubernetes管理）などの多層構造を通じて、統合的なAIインフラを提供する
Mojoが必要な背景と言語設計の決定
- 既存言語では、高性能MLカーネルの移植性とベンダー最適化という2つの要求を同時に満たせない
- Mojoはハードウェアの詳細構造、たとえば各種データ型（8ビット浮動小数点など）やTensor Coreのように革新的かつ急速に変化するハードウェアへ動的に対応できなければならない
- 型安全性を確保したメタプログラミングモデルによって、複雑なハードウェア制御をより効率的で共有しやすい形へ変換する
ハードウェアとカーネル設計の変化
- 現代のデータセンターのCPUは多数のコアへと拡張してきたが、GPUはSM（Streaming Multiprocessor）構造、Warp（32スレッド動作）など、並列処理特化設計として急速に進化してきた
- Tensor CoreなどAI専用演算ユニットがハードウェアとして導入されたことで、従来のCUDAとはまったく異なるハードウェアプログラミングパラダイムが必要になった
- 同一ベンダー内でもアーキテクチャ世代ごとの互換性変化が頻繁に起きており（例: Nvidia Volta/Hopper/Blackwellの変化）、ソフトウェアスタックがそれに追いついていない
ビジネスモデルとオープン生態系戦略
- Modularは言語そのものの販売に集中せず、Mojoを無料で公開している
- 中核的な収益モデルは、統合されたハードウェア管理とエンタープライズ向けのプラットフォーム/サービス提供に基づいている
- これにより、ベンダーロックインのない共通生態系の構築に挑戦し、多様なハードウェア対応と効率的なインフラ管理を同時に追求している
結論
- Chris LattnerとModularのMojoプロジェクトは、機械学習の高度化、AIハードウェア革新、生態系の分断克服に向けた新しいプログラミング言語およびプラットフォーム構築として意義を持つ
- 革新的な言語設計とオープン生態系の拡大を通じて、AI生態系の民主化と生産性向上に貢献しようとする戦略である
1件のコメント
Hacker News の意見
Mojo とポッドキャストに多くの関心を寄せてくれて感謝を伝えたい。Mojo についてさらに知りたいなら、FAQでよくある質問を確認できる（「なぜ Julia をもっと良くしないのか」への答えもある）。ドキュメントもこちらで確認でき、オープンソースコードも数十万行規模で公開されている。Mojo コミュニティも本当に素晴らしいので、Discourse フォーラムやDiscord チャットに参加してほしい - Chris Lattner の意見
ファンです。Mojo に関するいくつかの発表を見たが、Mojo が最先端のコンパイラ技術を活用しているとは言うものの、具体例を聞いたことがない。コンパイラ開発者でなくても 20% くらい理解できる程度でいいので、最先端技術の真価を感じられるような、かなり深く技術的なブログ記事を書いてほしい
FAQ で「Mojo Playground はまだ使えるのか？」と尋ねるとそのプレイグラウンドに案内されるが、肝心のその場所では「次の 25.6 リリースで Playground を削除する」と案内されている。「使えるのか」という FAQ の答えが、まもなく削除される機能を案内しているのは要点を外しているように見える。実際には「長くは使えない」が答えのようだ
Chris、ここで会えてうれしい。以前 Light Table を通じて投資もしたので、何かアップデートがあるのか気になっている。（本気で聞いているわけではないが、Mojo はかっこよく見える。）こうしたプロジェクトの長期的な持続可能性がどうなのか、信頼できる根拠があるのか気になる
Python が ML 分野を支配している理由は、現代の ML アプリケーションが単なる計算用スクリプトではなく、幅広い機能と堅牢なエコシステムを必要としているからだ。各種データ前処理（ETL）、多様な形式のデータ処理、高性能コンピューティングクラスタでの分散処理、可視化や GUI/DB 連携まで、すべてを包括する言語は Python のほかにない。数値演算は NumPy、PyTorch、JAX などが内部的に C/C++/FORTRAN を使っているため非常に速く、性能が重要なコードだけを別途 C/C++ で実装するのも容易だ。Python の C/C++ FFI システムも他言語に比べて十分実用的だ。他の言語（Julia など）でエコシステム全体を再実装するより、はるかに利点が大きい
Python のエコシステムが比類ないのはその通りだが、Elixir/Nx の組み合わせも Mojo が約束していることのかなりの部分をすでに実現している。EXLA を通じて GPU/TPU コンパイルも可能で、Explorer/Polars でデータフレーム処理、Pythonx で Python ライブラリの埋め込みもできる。違いがあるとすれば、Elixir は最初から分散システム構築を念頭に置いており、BEAM/OTP は膨大な同時リクエストや GPU ノード間の調整にも対応できることだ。実際に ML サービスを構築するなら、Phoenix、LiveView、Nx までを含むひとつの堅牢なスタックで極めて高い耐障害性と拡張性を得ることのほうが、わずかなハードウェア性能差より重要かもしれない
私は推論（inference）の面では少し違う立場だ。CUDA カーネルを直接いじって作るのは簡単で、最新の CUTLASS 3 や現代的な C++ はかなり使いやすくなっている。その上に Torch が薄く載っているが、この部分はビルドも難しく、参照カウントをはじめとするいろいろな問題で複雑さを増しているだけだ。本当の中核実装は下のカーネル側にあり、近いうちにこうした「torch のカバー」部分を取り払って、きれいな C++ プログラムとして明確につないで使うつもりだ
この問題は GPU カーネルの話であって、そうしたカーネルはそもそも Python で書かない。Python は ML のための「接着剤（glue）」言語だ。「Python だけがすべての機能を提供する」という主張には同意するが、より良い言語ではなく Python を中心にエコシステムが育ってきたことには少し残念さもある
Python が ML の代表言語になったのは「好循環」の結果だ。すでに選ばれていたからエコシステムが大きくなっただけで、最初に選ばれた理由は別途説明が必要だ。今では越えられないように見えるほど巨大になったが、なぜ最初から Python だったのかの根拠としては不十分だ
皮肉なことに、Python は挙げられたすべての作業にとって最悪の言語だ。パッケージングもバイナリ（wheel）も苦痛で、常に何かが壊れる。単独スクリプトには向いているが、ML の主要言語になることを目指して Python を設計していたなら、こんな姿を誰も望まなかったはずだ
エピソードを聞いて衝撃を受けた。2025 年 9 月になっても、まだクラス対応が中期目標だという話には驚いた。以前は Mojo が「Python の上位互換」だとかなり宣伝されていたが、現在の進捗速度では理想的な目標にしか見えない
実際には「Python の上位互換」が目標だったことはない。人々の関心を集めるためのスローガンにすぎず、初期だけ強調して静かに取り下げた
速度の問題ではなく、OOP 自体が好きではないからではないかと思う
ずっと長期目標だった
ありふれた質問かもしれないが、なぜ Lisp ではなかったのか気になる。将来の ML コードは結局マシン（あるいは自然言語ベースの自動変換システム）が書くことになると仮定すると、Lisp の S-Expression は事実上 AST と同じなので、マシンにとって最も自然な言語だ。REPL 環境も普通は一通り揃っているので、Python の代替としても非常によく合いそうだ
Yann LeCun らは Lush という ML 向け Lisp を作っていた。2000 年代には最高で、Python（Theano）や Lua（Torch）が登場するまでは代替がなかった。今でも Lisp が再び注目されてほしいと思っている。Python はライブラリは素晴らしいが、言語そのものには改善の余地が多い
LLM（大規模言語モデル）は、まだ括弧の数を数えるのが苦手だから ;)
過去の AI ブームのときに Lisp が敬遠された経験があるので、多くの開発者はいまだに Emacs + SBCL しか使わない。実際には LispWorks、Allegro、Clozure のような他の高級 Lisp 実装もあるが、試したことがない場合が多い
Mojo のライセンスがそもそも気に入らない
私も確認したが、Mojo のライセンスは CPU や Nvidia 用途と、それ以外の「アクセラレータ」（TPU、AMD など）を区別しており、商用利用なら別ライセンスが必要だと明記している ブログ参照
私の立場では、特定企業が絶対的に制御する言語（Mojo）なら、ビジネスで採用する理由はまったくない。Java のライセンス変更時にすでに多くの企業が問題を経験した前例がある。Python の代わりに Mojo に事業を載せるのはリスクが大きすぎる
Mojo FAQ を見ると、厳密な意味では Python の上位互換を目指すとしている一方で、ロードマップでは「Python コードとの親和性は提供するが、完全な上位互換にはなれない」としていて混乱が増すばかりだ。Python 互換が目標でないなら、なぜここまで Python に言及し続けるのかわからない。また、ファイル拡張子に絵文字を使うという話が本当にあるのか気になる
私の知る限り、Mojo は Python スタイルの構文と Python との相互運用性だけを目指している。それ以上に Python に似ていると訴えるのは、マーケティング色が強い
絵文字拡張子については本当だ。U+2615（コーヒーの絵文字）だ
Mojo が Julia より優れている点を知りたい。Julia にもインターフェースやエコシステムの限界はあるが、Python との連携も十分うまくできており、Mojo が特別に優れているようには感じられない
とくに Julia は JuliaGPU や Reactant のような GPU エコシステムがよく整っている Reactant.jl 参照
Python との互換性は Mojo のほうが少し良いかもしれないが、実際には PythonCall.jl を通じて Julia からでも Python ライブラリの呼び出しはかなり安定している。ML フレームワーク（Lux.jl、Flux.jl）も Julia 内でうまく動く。Mojo には同程度のネイティブ ML フレームワークがまだないように見える
Mojo ははるかに低レベル言語寄りの感触と、より多くの制御権、そして堅牢さを目指しているようだ。Julia は意味論や性能の面で予測可能性に欠け、基幹ソフトウェアの基盤には不向きだが、Mojo はその点で優位がある
Python モジュールを Julia で作ろうとしたが、まだサポート不足だと感じた。Mojo ではこの部分が中核機能だ
Julia コードを完全なネイティブバイナリとして（Rust や C++ のように）コンパイルする機能は、まだ不十分だ
Mojo がそこまで大きな注目を集めず、PyTorch の利用が依然として続いている点は、ライセンス問題が実際に予想以上に大きいことを示す手がかりかもしれないと感じる
Mojo は自分たちの領域を楽観的に捉えすぎたように思う。Julia も実際の商用利用が徐々に増えており、GPU 対応も良い。Python の JIT コンパイラが不十分だとしても、Nvidia や Intel などが Python DSL で GPGPU プログラミングをかなり最適化しているので、Python 内で C++ に近い水準まで使える。結局のところ Mojo は差別化要因が弱い
システム側の観点では、Chris とチームが Mojo で多言語 FFI 問題を一掃しようとしている試みは印象的だ。ただしオープンソースになるまでは、投資の話であれ議論であれ始めることはできない
まだ汎用プログラミング言語として使う準備ができていない。Modular も MAX エンジンに Mojo API を適用しようとしたが、言語の変化が速すぎて投資を断念した。ロードマップの第 1 段階が完了してから本格導入が期待される
本当に公開されていると言ってよいのかわからない。最近までオープンソース化されておらず、商用の独占ソフトウェアに依存することに抵抗があった
記事の冒頭を見ると「最先端カーネル」を使えるとある。結局 Mojo はカーネル開発において C++ と競争しようとしているようだ。PyTorch や Julia ではカーネルを直接書かず、主に高水準のコーディングをすることになる
Chris Lattner が参加した Lex Fridman ポッドキャストのエピソードがある:
Mojo の試み自体は大胆で興味深いが、Matlab のような閉鎖的言語なら、私だけでなく多くの人にとって深刻な欠点だ