Pythonの良いところって、結局エコシステムだけだよね。

彼らの最初の提案では、Pythonコードを取り込んで型ヒントを追加して、大幅に速度アップするっていうのが確かにあった。でも、実際に開発が進むにつれて、方向性がずれていったみたいだね。

コミュニケーションの中で、当然動くと思ってすごくシンプルなPythonコードを実行しようとしたんだけど、全然動かなかった。これにはかなりがっかりしたし、他の開発者たちにもどれだけ逆効果になってるのか気になるな。

それが元々宣伝されてたことだったんだ。KotlinがJavaに対してそうだったように、Pythonに対してもそうなりたかったんだよね。でも、すぐに手のひらを返した感じ。完全にオープンソースじゃない開発モデルも、ずっと怪しい感じがしてる。

サイトから: Pythonとの相互運用性 > MojoはPythonとネイティブに相互運用できるから、既存のコードを全部書き直さなくてもパフォーマンスのボトルネックを解消できるよ。最初は1つの関数から始めて、必要に応じてパフォーマンスが重要なコードをMojoに移行していけばいい。Mojoのコードは自然にPythonにインポートできて、配布用にパッケージ化もできるし、PythonエコシステムのライブラリをMojoコードにインポートすることもできるよ。

それってCodonで実現されてるんじゃないの？

確か、同等のPythonに対して36,000倍のスピードアップを宣伝してたけど、これは極端なケースでしか成り立たないってことを一切明言してなかった気がする。Pythonエコシステムを改善しようとする誠実な試みというより、むしろポンプ・ダンプの暗号通貨スキームみたいに感じる。

彼らは既存のPythonコードと互換性を持たせるつもりだった それが最初の主張だったけど、静かにウェブサイトから削除されたよね。（「Pythonはシンプルな言語」という一般的な誤解に引っかかったのかな？）今は「Pythonのように書ける」って約束してるけど、クラスのような基本的なものすらサポートしてない（それはロードマップのステージ3の一部だけど、まだステージ1に取り組んでる）。Mojoがすべての目標を達成するかもしれないけど、今のところは約束が大きくて実際はそれに届いてない感じで、V言語を思い出させるな。

よく見てたら、最初から次世代のシステム言語を作るつもりだったのは明らかだったよ。SwiftやRustからの教訓を活かして、CPU/GPU/異種ターゲットを狙って、MLIRを中心に構築していくって感じで。でも、最終的にはPythonを比較的簡単に埋め込んだり拡張したりすることも考えて作ってるみたい。Pythonの枠組みはお金を集めるのにほぼ確実に役立っただろうね。Chris LattnerはMLIRとMojoの関係について、PythonとMojoの関係よりも多く語ってたよ。

それはMojoがそう言ったからだよ。https://web.archive.org/web/20231221132631/https://docs.modu... > 私たちの長期的な目標は、MojoをPythonのスーパーセットにすること（つまり、既存のPythonプログラムと互換性を持たせること）です。Pythonプログラマーは、すぐにMojoを使えるようになり、今日利用可能な膨大なPythonパッケージのエコシステムにアクセスできるはずです。

MLに関心がある者として、Mojoの成功を願ってるよ。特に、GPUとCPUのコードを同じ言語で混ぜられる可能性が楽しみ。でも、彼らがやってる変更がPython開発者を遠ざけるんじゃないかと心配してる。オープンソースじゃない限り、ほとんどのPython開発者は来ないだろうし、意味がないよね。

Mojoはかっこいいけど、Pythonの後方互換性のことがよくわからない。これが足かせになってる気がする。Kotlinの欠点はJavaとの互換性に起因してると思う。もっと明確にすればうまくいったかもしれないけど、今のやり方じゃうまくいかない気がする。

その点に関しては、Nimプログラミング言語を再現しようとしているように見えるね。

面白いね、CuTileの影響ってどれくらい大きいの？

みんなMojoをGPUコードを書くための良い構文だと勘違いしてるけど、NvidiaのPythonフレームワークがすでにそれをやってると思ってるみたい。でも…CuTileはAMDのGPUやApple Siliconで動くのかな？Nvidiaがやることにはベンダーロックインがあるからね。

それに遅れを取らないために、IntelとAMDも似たような努力をしてるし、CPythonのJITがようやく実現しそうだね。GraalPyやPyPyのような取り組みもあるし。これらの努力は、Windowsでも動作するから、サーバーがLinuxディストリビューションでも、ほとんどの社員がWindowsを使ってる企業には関係あるよね。これがまたSwift for TensorFlowみたいな結果にならないか心配してる。

コーディングエージェント（ちゃんと指示すれば）は、コードをループで動かそうとするからね。静的型付けとコンパイルはそのプロセスに役立つ（例えば、実行時に未定義の変数が見つかることがなくなる）。でも、これが完全に安全ってわけじゃないってのはみんな知ってるよね。

AIが注目されるようになってから、これらの製品やサービスのヒーローページでの必死さを見るのが本当に興味深い。私にとって一番面白かったのは、IBM DB2の製品ページを開いたら「AIデータベース」ってラベルが付いてたこと。爆笑だよ。 > どうして、または、コンパイル時により多くのエラーが捕まるっていうのは、エージェントがユニットテストや他のテストなしで静的に自分の作業をすぐにチェックできることを意味する。

それが何を意味してるのかは分からないけど、「AIネイティブ」ってこのプログラミング言語にとってはちょっと意味がないと思う。コンパイルと静的型付けについては、エージェントプログラミングをする際にコンパイル時に問題を検出できるのは非常に助かるよね。そうすれば、実行時に問題が少なくなるし、もちろんエージェントはそれに対処するのが難しくなる。ユニットテストはそのギャップを少し埋めるのに役立つけど、完全には埋められない。彼らのウェブサイトには書かれてないけど、Mojoはエージェントプログラミングにはあまり向いてないかもしれない。なぜなら、Mojoのトレーニングデータがまだあまりないから。

自分を「AI好き」って思ってるわけじゃないけど、使ってるよ。エージェントはフィードバックが多いほどうまくいく傾向があるし、型チェックはバカなミスを自動でキャッチするのに結構役立つ。要するに、エージェントにヒントをたくさん与えるのが大体の場合は良いってことだね。

https://mojolang.org/docs/tools/skills/

それは新しい「…ブロックチェーン上で」みたいなものだね。Python+ruff+pycheckとTypeScriptは、機械コードではなくバイトコードにコンパイルされる。Rustの意味で静的型付けされてるわけじゃない。それでも、モデルがそれらのどちらでも良い、有効なものを生み出すのを見てきた。厳密に「コンパイルされた」り「静的型付けされた」りする必要はないみたい。結局、AIは良いツールがあればコードをすぐにチェックして反復することに関しては、そんな特性を気にしないみたいだね。

現在のLLMは過去のコードの膨大なライブラリでトレーニングされているから、今後しばらくは確立された言語の方が新しい言語よりも良く機能するだろうね。特に、Pythonのようにオープンソースコードがたくさんある言語はね。既存のコードがない企業にとっては大きな問題だよ。だから、この必死な「AIネイティブ」マーケティングは、エージェント的な世界で relevance を持つためには必要なんだろうね。それが十分かどうかは、時間が教えてくれるよ。

同じような感じだな。これって、数十年前にニューラルネットやAIが作られた時の最初の言語、Lispの仲間だったはず。Swiftの素晴らしいプロジェクトから来てるけど、Appleの幹部を納得させるのは大変だったよね。それでも、Haskellのような関数型言語のアプローチとClojureの実用性を期待してたんだ。

現実世界のMLコードの大半は今、PythonやC++のような言語で書かれてる。学術界やオンラインフォーラムの外では、関数型言語の愛好者はあまりいないしね。業界的にも、実際のコーディングは今後LLMがやることになりそうだから、新しい言語をニッチな潜在ユーザーベース向けに設計するのはあまり意味がないと思う。LLMは大量のトレーニングデータが必要だからね。だから、MojoをPythonベースにすることにしたのも、彼らが言ってる他の理由と合わせて、そういう要素があったんじゃないかな。

ノイズの中からいい発見だね。ありがとう！

PythonのcuTile JITコンパイラは、純粋なPythonでCUDAカーネルを書くことを可能にしてる。今は純粋なPythonじゃないし、これからもそうならないよ。これらの「パフォーマンスに優しい」Python方言（Tryton、Pythran、CuTile、Numba、Pycell、cuPyなど）は、一見Pythonっぽいけど、表面をちょっとこすっただけで全然違うってわかる。彼らはPython風の構文を持つDSLだけど、最適化されて、型付けされて、正しく推論されるように作られてる。使ってみるとそれを感じるよ。どれもPythonの機能の多く（ほとんど？）が使えないし、Pythonの本質的な問題に苦しむことになる。自分たちに嘘をつくのはやめよう。Pythonは効率とパフォーマンスにおいて本質的に悪い。GILを超えて、動的型付け、参照セマンティクス、モンキーパッチ、超動的オブジェクトモデル、CPython ABI、デフォルトのBigInt、ランタイムモジュールシステムなど、全てが小さなスクリプト言語には意味がある技術的選択だけど、HPCや効率にはひどく合わない。Numpyやscipyのエコシステム自体も、単純なCPUバウンドのテンソル演算のためにPythonの制限を回避するためのハックに過ぎない。主に、組み込みのPythonのパフォーマンスがひどすぎて、単純なforループがExcelを競走馬のように見せるから。Mojoは違う。Mojoは既存のクソをハックするんじゃなくて、クリーンな状態から始めようとしてる。そして、「Pythonのような体験」を提供しようとしてるけど、過去の言語設計の経験をもとにしたしっかりしたデザインの上に成り立ってる（Pythonは30年以上前のものだし）。そのためだけでも、成功を願ってるよ。

私も！バイオインフォマティクス関連の仕事で使ってるけど、ほんとに素晴らしいよ。完全にオープンソースになったら、もっと簡単におすすめできるのが待ちきれない！

CythonやPyBind、Nanobindは、C++で書かれた既存のライブラリをラップして、C++っぽくないインターフェースを作るのに良いよね。ctypesやSWIGからの大きなステップだった。

Mojoは、Rustよりもプログラミングモデルが簡単で、Python開発者には馴染みやすい構文を持ち、全体的にモダンなデザインを目指している言語だよ。今の目標は、Pythonを拡張する最も簡単な方法を提供すること。 .mojoファイルを手間なくインポートできる同じインターフェースを提供しているんだ。