Mojo 1.0 ベータ
(mojolang.org)- Mojo は「Pythonのように書き、C++のように実行する」言語を掲げており、現在の安定版として 1.0.0b1 (May 7) を提供している
- CPUからGPUまで多様なハードウェアで高速なコードを書きつつ、特定ベンダーに依存しないことを目標とし、現代の AIシステム 向けの高性能な静的型付け言語として設計されている
- Python相互運用 をネイティブでサポートし、既存コードをすべて書き直さずに性能ボトルネックだけをMojoへ移せるほか、MojoコードのPython importとPythonライブラリのimportの両方をサポートする
- 同じ言語で GPUカーネル を書くことができ、ランタイムコードと同じ言語を使う コンパイル時メタプログラミング によって、ハードウェアごとの最適化とゼロコスト抽象化を提供しようとしている
- Mojo標準ライブラリは GitHubで完全にオープンソース として公開されており、コントリビューションを受け付けている。Mojoコンパイラは 2026年にオープンソース化 を計画している
バージョンと開始資料
- 現在の安定版は 1.0.0b1 (May 7)、最新nightlyは May 9
- MojoはPythonの直感的な文法、Rustのメモリ安全性、Zigの強力で直感的なコンパイル時メタプログラミングから着想を得ている
- コンパイルされる静的型付け言語として、エージェント型プログラミングにも適している
- 生産性と性能のどちらか一方を選ぶのではなく、その両方を提供することを目標としており、単純で馴染みのあるプログラミングパターンから始めて、必要なときに複雑さを追加できる
- 開始手段として Install Now、Quickstart、Releases、Roadmap、GitHub が用意されている
- Markdownでページを見るにはURLに
.mdを付ければよく、Mojo文書全体のインデックスは llms.txt で確認できる
GPUとPython相互運用
-
GPUプログラミング
- Mojoは、ベンダーごとのライブラリや別個のコンパイルコードなしでGPUプログラミングにアクセスできるようにすることを目標としている
- CPUに使うのと同じ言語で高性能なGPUカーネルを書ける
- 例のカーネル
vector_addはTileTensorを受け取り、global_idx.xを基準にresult[i] = a[i] + b[i]を実行するdef vector_add( a: TileTensor[float_dtype, type_of(layout), element_size=1, ...], b: TileTensor[float_dtype, type_of(layout), element_size=1, ...], result: TileTensor[ mut=True, float_dtype, type_of(layout), element_size=1, ... ], ): var i = global_idx.x if i < layout.size(): result[i] = a[i] + b[i]
-
Python相互運用
- MojoはPythonとネイティブに相互運用でき、既存コードをすべて書き直さずに性能ボトルネックを取り除ける
- 1つの関数から始めて、必要に応じて性能が重要なコードをMojoへ移していく形で拡張できる
- MojoコードはPythonに自然にimportされ、配布用パッケージとして一緒にまとめられる
- 逆に、Mojoコード内でPythonエコシステムのライブラリをimportすることもできる
- 例の関数
mojo_square_arrayはPythonObjectのctypes.dataからポインタを取得し、SIMD幅をコンパイル時に計算して配列要素を二乗する# SIMD-vectorized kernel squaring array elements in place. def mojo_square_array(array_obj: PythonObject) raises: comptime simd_width = simd_width_of[DType.int64]() ptr = array_obj.ctypes.data.unsafe_get_as_pointer[DType.int64]() def pow[width: Int](i: Int) unified {mut ptr}: elem = ptr.load[width=width](i) ptr.store[width=width](i, elem * elem) vectorize[simd_width](len(array_obj), pow)
コンパイル時メタプログラミング
- Mojoのメタプログラミングは、ランタイムコードと同じ言語を使って性能を最大化する直感的なシステムを提供する
- 条件付きコンパイルによってハードウェアごとの最適化を作り、コンパイル時計算によってメモリ安全性を保証し、コストの高いランタイム分岐を取り除ける
- 意図を明確に表しつつ、ゼロコスト抽象化を提供することが目標
- 例の
__eq__実装は、コンパイル時リフレクションで構造体フィールド名と型を取得し、すべてのフィールドがEquatableを満たすかを検査したうえで、フィールドごとのequalityを行う# Generic struct equality using compile-time reflection. @always_inline def __eq__(self, other: Self) -> Bool: comptime r = reflect[Self]() comptime names = r.field_names() comptime types = r.field_types() comptime for i in range(names.size): comptime T = types[i] comptime assert conforms_to(T, Equatable), "All fields must be Equatable" if trait_downcast[Equatable]( r.field_ref[i](self) ) != trait_downcast[Equatable](r.field_ref[i](other)): return False return True
ロードマップとオープンソース
- Mojoは2022年末に始まり、まだやるべきことが多い
-
Phase 0
- 初期基盤の構築段階
- コアパーサー、メモリ型、関数、構造体、イニシャライザ、引数規約、そのほかの言語基盤を実装する段階
-
Phase 1
- 現在進行中の段階
- CPU、GPU、ASICで高性能カーネルを書ける強力で表現力のある言語にし、開発者がPythonをシームレスに拡張できるようにすることが目標
-
Phase 2
- システムアプリケーションプログラミング段階
- 保証されたメモリ安全性モデルと、システムプログラミング開発者が期待する、より多くの抽象化機能をサポートするよう拡張する段階
-
Phase 3
- 動的オブジェクト指向プログラミング段階
- Pythonコードとの互換性を最大化するため、クラス、継承、型なし変数のようなPythonの動的機能をさらに多くサポートする段階
- 詳細は Mojo roadmap で確認できる
- Mojo標準ライブラリは GitHubで完全にオープンソース として公開されており、コントリビューションを受け付けている
- Mojoコンパイラは2026年にオープンソース化する計画
- Mojo全体をオープンソース化する方針だが、言語がまだ非常に若いため、共通ビジョンを持つ緊密なエンジニア集団のほうがコミュニティ主導方式より速く動けると判断している
- 参加手段として developer community が用意されている
学習およびコミュニティ資料
- Install および Quickstart guide: Mojoの開始資料
- Beginner tutorial: Game of Lifeを作りながらMojoを学ぶ
- GPU puzzles: パズルを解きながらMojoでGPUプログラミングを学ぶ
- Intro to Mojo: Mojo言語機能全般の紹介
- Developer forum: Mojoに関する質問とアップデート
- Events: イベント、ミートアップ、発表、ハッカソンの案内
- Contributions: オープンなIssue、ドキュメントへのコントリビューション、プロジェクト共有の案内
1件のコメント
Hacker Newsの意見
この2年間、趣味で Mojo をかなり使ってきたが、本当にすばらしい言語だと思う
Rustに近い所有権モデル、Zigより強力なコンパイル時実行、豊富な型システム、一級のSIMDサポートなどがある
性能面でも、久しぶりに単なるLLVMラッパーではない言語のように見える。LLVMは引き続き使っているが、RustやZigとは異なる形で活用している
今年末にオープンソース化されれば、Mojoには大いに期待している
今のMojoのドキュメントを見る限り、その結論にはなかなか至れない
機械学習をしつつ性能にも関心がある立場としては、Mojo には成功してほしい。特に、同じ言語でGPUコードとCPUコードを混在させられる点に期待している
ただ、今の変化がPython開発者を遠ざけてしまわないか心配でもある。最後に試したとき、基本的な文字列操作をテストしようとして
var x = 'hello'; print(x[3])をやってみたが動かず、len(x)も使えなくて1時間悩んだ後でわかったのは、バイト表現とコードポイント表現をより明確に分ける方針だったということだが、ドキュメントが実装と矛盾していた
一般的な機械学習にも使える状態になってほしいが、現時点ではまだかなり制約が多い印象。Tensor関連のまともな基本機能も一部廃止された
当面はJAXを使いながら、ときどき様子を見るつもりだ
こういうのはコンパイラや言語設計に関心のある人たちが夢見るようなものではないだろうか
どんな状況でも効率を保証したり最先端の性能を出したりする必要はなく、ただ存在するだけでも十分うれしい
こういう言語を作ること自体は可能だと理解しているが、作れる人たちの興味を引けていないのだと思う
Kotlinで思い浮かぶ欠点のほとんどはJava互換性が原因だ。こちらではもっと明示的なやり方でうまく解決できたかもしれないが、今の方式は失敗する運命に見える
「Mojoを2026年秋にオープンソースとして公開すると約束した」とある
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
残念ながら、その間にNvidiaもじっとしていたわけではなく、MLIRベースの似たコンパイラスタックを通じて、Python向け、そしてまもなくC++向けの CuTile という次世代CUDAを作った
移植性はなくても、Nvidiaが強力に推進し、開発ツールに統合され、既存のCUDAコードと共存できるという理由だけで、Mojoよりはるかに広く使われる可能性が高い
Tile IRは、MojoよりもTritonの脅威への対応に近かった可能性が高い。そこそこの性能が出るLLMカーネルをどれだけ簡単に書けるかという観点では、特にそう思う
GraalPyやPyPyのような試みもある
こうした取り組みはどれも現在Windowsで動く。会社で従業員の大半にWindowsマシンが支給され、サーバーだけLinuxディストリビューションを使うような環境では、これはかなり重要だ
これもまた別のSwift for Tensorflowのような結末になるのではないかと、どうしても考えてしまう
顧客からのフィードバック以外で、何かへの対抗だと言っていた人はいなかった
だが、CuTileはAMD GPUやApple Siliconでも動くのだろうか。Nvidiaが何をしようと、結局 ベンダーロックイン は残る
最初にMojoを聞いたときは、既存の Pythonコードと互換 のあるものを作ろうとしているのだと思っていた
だが近い将来、その目標からはかなり遠いように見える。PythonとMojoの間で相互に呼び出すことはできるが、Mojo自体が既存のPythonコードを実行できるわけではない
しかし実際に作っていく中で、方向性が変わったように見える
Pythonエコシステムを改善しようとする誠実な試みというより、パンプ・アンド・ダンプ型の暗号資産計画のように感じられる
SwiftとRustの教訓を取り入れ、CPU/GPU/異種ターゲットを狙い、MLIRを中核に据えた言語だった
同時に、いずれPythonを比較的容易に埋め込んだり拡張したりできることも視野に入れた構造で、Pythonというフレーミングは資金調達にもほぼ確実に役立ったはずだ
Chris LattnerはPythonとMojoの関係よりも、MLIRとMojo の関係について多く語っていた
その点と、完全にオープンソースではない開発モデルのせいで、ずっと ベイパーウェア のように感じていた
Python相互運用性: 「MojoはPythonとネイティブに相互運用できるため、すべてを書き直さなくても既存コードの性能ボトルネックを解消できます。1つの関数から始めて、必要に応じて性能が重要なコードをMojoへ移していくことができます。Mojoコードは自然にPythonへインポートされ、デプロイ用に一緒にパッケージ化されます。同様に、PythonエコシステムのライブラリをMojoコードへインポートすることもできます」
Mojoは悪くなさそうだが、CPUとGPUをまたぐ 高性能数値計算 という点では、今はJuliaにかなり満足している
Pythonのような構文であることを除けば、このニッチはすでにほぼ解決済みに思える。Pythonですら、NumbaやTritonのように、より複雑さが少なく独立性の高い種類の問題に有効なツールがある
同じ目的なら Julia のほうが成熟しており、昨年からNvidiaはCUDAでPythonツールとC++ツールの機能同等性をそろえつつある
Python cuTile JITコンパイラを使えば、純粋なPythonのようにCUDAカーネルを書ける
AMDとIntelも同様のアプローチを追っている
Mojoがより広い採用を得るのに間に合うかどうかは、まだ見守る必要がある
こうした「性能志向」のPython方言、つまりTriton、Pythran、CuTile、Numba、Pycell、cuPyなどは、見た目こそPythonに見えるが、表面を少し削ればまったくPythonではない
最適化と型推論がうまく働くように作られた Python風DSL だ。実際に使えばそう感じる。どれも多くの、あるいはおそらく大半のPython機能が使えないのに、Python固有の問題は依然として背負うことになる
正直なところ、Pythonは効率や性能に本質的に向いていない
これはGILをはるかに超えた問題だ。動的型付け、参照セマンティクス、モンキーパッチ、極めて動的なオブジェクトモデル、CPython ABI、標準のBigInt、ランタイムモジュールシステムなどは、小さなスクリプト言語としては理にかなっていても、高性能計算や効率の観点では非常に不利だ
NumPy/SciPyエコシステム自体も、単純なCPUバウンドのテンソル算術のためにPythonの限界を回避するハックに近い
素のPython性能があまりにも低いため、単純なforループですらExcelが競走馬に見えるほどだからだ
Mojoは違う
Mojoは既存の問題だらけの基盤をハックするのではなく、クリーンな出発点 から始めようとしている
そして30年以上前のPythonではなく、これまでの言語設計の経験を踏まえてよく設計された言語として、「Pythonのような体験」を提供しようとしている
それだけの理由でも成功してほしい
最近は、少なくとも一部の人たちには AI native を前面に出した宣伝が必要なのだろうと思う
だが自分には少し拒否感がある。実際には何も言っていない表現に見えるからだ
「コンパイルされ、静的型付けされた言語なので、エージェント型プログラミングにも理想的だ」というのが、なぜそうなのか、何を意味するのか、AIに熱狂している人たちは説明できるだろうか
個人的にいちばん笑ったのは、IBM DB2の製品ページを開いたら AI database と書かれていたことだ
コンパイル時により多くのエラーを捕まえられれば、エージェントは単体テストやほかのテストなしでも、自分の作業を静的に素早く確認できるという意味だと思う
とりわけPythonのように利用可能なオープンソースコードが多い言語は有利だ。学習する既存コードがない新規参入者にとっては大きな問題になる
だからこそ、「エージェント型」の世界で関連性があるように見せるには、こうした必死な AI nativeマーケティング が必要なのかもしれない。それで十分かどうかは時間が答えを出すだろう
エージェントはフィードバックが多いほど、うまく動く傾向がある。型チェックは、くだらないミスをかなり自動で拾うのに向いている
要するに、エージェントには ヒントが多いほど たいてい良いということだ
コンパイルや静的型付けについて言えば、エージェント型プログラミングではコンパイル時に問題を検出できることがとても役立つ
そうすれば、ランタイムで遭遇する問題が減り、エージェントが解決しにくい状況も減る。単体テストである程度そのギャップを埋められるが、完全ではない
ウェブサイトに書かれていないのは、Mojoはエージェント型プログラミングにはむしろ不向きな選択肢である可能性が高いということだ。まだ Mojoの学習データ があまりないからだ
Python+ruff+pycheckやTypeScriptは機械語ではなくバイトコードにコンパイルされる。Rust的な意味での静的型でもない
それでもモデルがどちらでもかなり良い有効なコードを生成するのを見てきた。厳密に「コンパイル」されたり「静的型付け」されていたりする必要はなかった
結局のところ、AIはコードを素早く確認して反復できる 良いツール さえあれば、そうした性質にはあまりこだわらない
Modularは今年末、コンパイラを含む完全な Mojo SDK をオープンソースとして公開する予定だ
「Mojo 1.0は今年末に確定し、コンパイラ公開と言語安定性の提供もそれに合わせて進められる」とある
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Mojoを引き続き追っている。正直、Pythonでいちばん気に入らないのは 構文 だ
ここで別の人がJuliaに触れていたが、良い言語だと思う。ただ、コンパイラのエラーメッセージやライブラリのドキュメントは、その程度に成熟した言語として期待する水準には達していない
以前読んだブログの正確性の問題も気になっている。また、バイナリサイズと初回実行時間のせいで、自分が望む形のPythonモジュールをJuliaで作れる気がしない
それでもMojoが選択肢になってほしいとは思っている。ただ、自分はREPLが好きだし、Pythonの動的な性質も好きなので、性能のためにNumPyの外へ出ることは結局ないかもしれない
だから Nim が本当に好きだ。C級の速度、コンパイル時実行、メタプログラミング、強力な型システム、メモリ安全性を得ながら、コードもしばしば短く優雅になる
Mojoも面白いが、これまでのところ汎用プログラミングより機械学習寄りに重点を置いているように見える。そしてコンパイラはまだオープンソースではないはずだ
Mojoは産業用途に耐える堅牢な言語になることに、より重点を置いているようにも見える。Juliaの最初の事前コンパイル実装がファイル入出力を提供していないのを見て衝撃を受けた