わぁ、ちょっと見てみたけど、商業目的でCPUとNvidiaを分けて、他の「アクセラレーター」（TPUやAMDみたいな）とは別にしてるみたい。 他のアクセラレーターにはライセンスのために連絡しないといけないんだって。 https://www.modular.com/blog/a-new-simpler-license-for-max-a...

私の素朴な考えでは、非営利団体ではなく単一の企業によって管理されている言語は、スタート地点にも立てないと思う。Javaのライセンス変更の時に、どれだけの企業が反応したか見てみて。Pythonの代わりにMojoのような言語にビジネスを基づけるのは、バカか、私には理解できないほど賢い人だけだと思う。

Mojoはかなり低レベルに見えるし、コントロールの度合いも高いね。それに、もっと堅牢な感じがする。Juliaはセマンティクスやパフォーマンスが不安定で、Mojoが目指すような基盤ソフトウェアには向いてないと思う。

特に、JuliaにはJuliaGPUやReactantみたいなユーザーフレンドリーで堅牢なGPU機能があるからね。他にも一般的なJuliaコードをGPUに変換するオプションがたくさんあるし。 1: https://enzymead.github.io/Reactant.jl/dev/ 2: https://enzymead.github.io/Reactant.jl/dev/

Pythonとの相互運用性はちょっと良さそうだね。でも一方で、PythonCall.jl（JuliaからPythonを呼び出せるやつ）はかなり良くて安定してる。Juliaには結構いいMLフレームワーク（Lux.jlやFlux.jl）があるし、Mojoに同じように使えるネイティブなMLフレームワークがあるかは分からないな。

Mojoってカーネルを書くために作られたんじゃないの？記事の冒頭にも書いてあるじゃん。> 最先端のカーネルを書くために。JuliaとPythonは、高水準言語で、カーネルが存在する他の言語を呼び出すんだよね。

[0] https://danluu.com/julialang/

MojoがJuliaにはできないことって何か知ってる？AoTコンパイルのファーストクラスサポートだよ。https://docs.modular.com/mojo/cli/build そう、Juliaにも実行可能ファイルを作るオプションはいくつかあるけど、なんか後付け感があるよね。

• 任意のJuliaコードをネイティブスタンドアロンバイナリ（rust/C++風）にコンパイルすること、そのすべての影響を伴って。

JuliaでPythonモジュールを作ろうと調べたけど、今のところあんまりサポートされてないみたい。対して、Mojoではそれがコア機能なんだよね。

上に書いてあるけど、> 最先端のカーネルを書く Mojoはカーネルを書くためにC++と競争してるみたい。PyTorchやJuliaは高レベルの言語だから、カーネルを書くことはないし。

まだベータ段階だから、ちょっと使いづらいね。Mojoは実質的にはModularが公開した内部ツールなんだ。1.0の状態になるまでは、真剣に使われることはないと思う。でも、他の人が言ってたように、PyTorchとは競争してなくて、CUDAと競ってるんだよね。

個人的には、ちょっとやりすぎた感があるかな。まず、Juliaが好きな人も結構いるし、HNでどう言われようと商業利用は着実に増えてるし、GPGPUのサポートもあるからね。一方で、PythonのJITコンパイラの状態が悪いとしても、少なくともNVIDIAとIntelはGPGPUプログラミングのためのPython DSLに真剣だから、PythonのままでC++のパフォーマンスに近づけるんだよね。だから、結局Mojoはあんまり魅力的じゃないかな。

まだまだ不完全な感じがするね。> もしかしたら1年、18ヶ月後には[...] クラスを追加するよ。

本当にリリースされたの？前にチェックしたときはオープンソースじゃなかったし、プロプライエタリなバポーウェアスタックに頼りたくないんだよね。

一般的なプログラミングにはまだ準備が整ってないよ。Modular自体はMAXエンジン用のMojo APIを提供しようとしたけど、言語が急速に進化しすぎてその投資を諦めざるを得なかった。ロードマップによると、フェーズ1が完了したらもっと採用が進むと思う。1. https://docs.modular.com/mojo/roadmap

私はシステム側にいるけど、クリスとチームがMojoでやってることは結構面白いと思うし、ポリグロットのFFIの混乱を解消するのに役立つかもしれない。ただ、実際にオープンにならない限り、投資したり使う議論を始めたりすることはできないな。

彼らはオープンソースにする前に本格的な採用は見込めないだろうね。今のプログラミング言語のルールとして、力を持って強制できないならそうなるし、Modularにはその力がない。クローズドソースの言語には、もう何度も痛い目にあった人が多すぎる。

ライセンスがこの言語の大きな障害になってると思う。新しいクローズドスタックに投資したい個人や組織はほとんどいないからね。CUDAが受け入れられてるのは、長い間存在していたからだし。GPGPUには、Linuxのような瞬間が必要だね。

市場はこういうものに対してかなり効率的だよね。過去10年でいくつかの異なるMLソリューションが急速に普及したのに、Mojoはあまり進展がない。これは、ユーザーが直面している現実の痛点を解決していない明確なサインだと思うし、どんなに実行が良くても、少数の人にしか魅力がないニッチなソリューションを作っているんじゃないかな。

Pythonの上位互換を目指してたわけじゃないよ。それはモメンタムを作るための話題だったけど、目的が達成されたら静かに放棄された。

それはずっと長期的な目標だったんだ。

最初のプロットまでの時間と実行可能なサイズは今どうなってるの？前回は200MBのハローワールドを表示するのに数秒かかってた。進展はしてると思うけど、もうそこに到達してるのかな？

JuliaがMLにとって「素晴らしい」とされる理由は何？

なんで誰かが動的型付け言語から別の動的型付け言語に移るのか、全然理解できない。下で引用されてるカーネルの例も「うーん、型は好きなように設定できる」って感じだし。まあ、もしかしたら動的型付け言語の実用に縛られてるのかもしれないし、「ML向け」ってのは「Jupyterノートブックでコーディングしてる」って意味かもしれないから、#2の人が何が起こってるか理解できるかどうかなんて気にしないのかもね。

もっと多くの人の関心と開発者の注目が必要だね。それが問題なんだ。JuliaはPythonの人気には勝てない。Pythonの競合は、そのエコシステムと100%互換性がないとダメだよ。

この人はGPUカーネルについて心配してるけど、GPUカーネルは絶対にPythonで書かれないよ。君が指摘してるように、PythonはMLのための接着剤みたいなもんだから。> Python以外に、これらすべての機能を提供できるリッチなエコシステムを持つ言語はない。確かにそうかもしれないけど、私たちの中には、少なくとも平均的にイライラする言語の周りで成長したことにまだ恨みを持ってる人もいるよ。

Pythonのエコシステムは打破するのが難しいけど、Elixir/NxはMojoが約束することの多くをすでに実現してる。EXLAはXLAを通じてGPU/TPUコンパイルを提供し、Mojoのデモと同じくらいのパフォーマンスを出すし、ExplorerはPolarsを使ってデータフレームを扱える。さらに、Pythonxを使えば、必要な専門ライブラリを使うときにPythonを埋め込むこともできる。実際のMLサービスを構築してるなら（単にカーネルを最適化するだけじゃなくて）、Phoenix / LiveViewからNxまでを一つのスタックで極端な耐障害性のために構築する方が、ハードウェアから最後のパフォーマンスを引き出すより重要かもしれない。

Python以外に、上記の機能をすべて提供できるほどリッチなエコシステムを持つ言語はない。C++やJavaがリッチなエコシステムを持ってないとは信じがたい。良いグルー言語にはならないとは言わないけど、Pythonがこんなに人気になる前は、みんなそれらの言語で書いてたからね。

幸運なことに、Chrisは自分が何をしているか分かってるよ。 https://docs.modular.com/mojo/manual/python/

推論の面ではちょっと違う立場にいるんだ。孤立して構築するのは比較的簡単な、すごくチューニングされたCUDAカーネルがあって、そこで全ての魔法が起こるんだ。それに新しいCUTLASS 3のやつもあって、モダンC++なら簡単に呼び出せるしね。だけど、どんどん薄くなっていくtorchのクソみたいなものがあって、ほぼビルド不可能で、リファレンスカウントや壊れたsetup.pyを引きずり込んで、リアルなハッカーの世界からの上下の投影があるんだ。もう少しでそのゴミを押し出して、何でもリンクできるきれいで整ったC++プログラムができそうな気がしてる。

ファンです。mojoについてのあなたのトークをたくさん見たけど、mojoが非常に高度なコンパイラ技術からどう利益を得ているかについて具体的な例を見たことがないんだ。ぜひ、そのことについてブログを書いて、できるだけ深く、ハードコアな技術を教えてもらえないかな？コンパイラの開発者じゃないから、たぶん20%くらいしか理解できないと思うけど、全体がどれだけ進んでいるのかを感じ始められたらいいな。

Swiftのおかげで、今まで使った中で一番いい言語の一つだと思う（ツール周りはちょっと残念だけどね）。それにGDScriptも、理由は色々だけどね^^

FAQは「Mojo Playgroundはまだ利用可能ですか？」って質問に対して、プレイグラウンドを指し示してるけど、プレイグラウンド自体は「次の25.6リリースで削除されます」って言ってるんだよね。だから「これが利用可能ですか？」っていうFAQの答えが、いつか削除されるって言ってるものを指し示すのはちょっとズレてる気がする。もしかして答えは「長くはない」ってことなのかな？

ねえクリス、ここで会えて嬉しいよ。Light Tableの重いキックスターターが実を結ぶのをまだ待ってるんだけど、何か進展ある？（本当に、これクールだね；こんなプロジェクトからどのくらいの持続性を期待できるのかな - どうやって確信できる？）

それで、ちょっと疑問なんだけど、例外の正しい使い方って何なの？ Pythonではイテレータが終わりに達したら例外を投げるって言ってるけど、もし自分のカスタムCイテレータがそれをやったら間違いなのかな？ やっぱり「for i in whatever: do(stuff(i))」みたいなのをやりたいんだけど…

Mojoの例外はResult型のための文法的な糖衣に過ぎないよ。使いたくなければ使わなくてもいいし、C++の例外のようなオーバーヘッドはないからね。

LLMは括弧を正確に数えるのが苦手だよね。 ;)