John Carmack、Goose言語を絶賛「ほぼすべてが可能になる」

Gooseに詳しい方に興味があるのですが、任意の数の動的にサイズが変わる値をどう表現するのですか？スタックの数が固定なら、同時にサイズを変えられる値の数も固定されるように思えます。

例えば、値が文字列のハッシュテーブルで、ランダムに文字列を挿入したり削除したりする場合、どう表現しますか？

これは簡単には表現できないように思えます。思いつく唯一の方法は、すべての文字列を保持するスタックを用意し、定期的にコンパクションするというものです。

追記: サイズごとに別々のスタックを用意する方法もあるかもしれません。8バイト未満、16バイト未満…といった具合に。しかしその時点で、事実上手作業で独自のmallocを実装しているようなものです。

追記2: 念のため言っておくと、Gooseはとてもクールだと思います！以前Rustでメモリ管理を高速化するために、似たようなものをたくさん手書きしたことがあります。

「何も共有しないスレッド。ワーカーは独自のメモリを持つ別プログラムとしてコンパイルされ、フラットな値は型付きキューをmemcpyで通過する。データ競合、ロック、アトミック、メモリオーダリングはこの言語には存在しない。」

これはDartのIsolatesを思い出させますね - https://dart.dev/language/isolates

MLの人たちがこの方向に進んだのを覚えています。たしかリージョンと呼んでいたはずです。

文献を少し読んだ限りでは、メモリ使用量がかなり増えるプログラムが十分にあったため、このアプローチは行き止まりだと判断したと記憶しています。

どなたか詳細をご存知ですか？

「とても素晴らしいですね！自動解析と複数のデータスタックおよびサイズ変更可能なフィールドの使用により、『多くの作業がこの方法でできる』から『ほぼすべてが可能になる』へと進化しています。

相対参照と組み込みのバイナリ構造検証により、データ構造の直接メモリマッピングとネットワークデータの即時利用も可能になります。ファイルやネットワークデータの『パース』は、必要以上に100倍遅いことがよくあります。」 - John Carmack

とても興味深いですね！私は主にガベージコレクション言語で書いているので（手で何かを書くことがまだあるとしても）、メモリ管理の議論ではただの傍観者ですが、ヒープ管理は科学というより芸術だといつも感じていました。メモリをよりスタックのように扱うというアイデアは、すぐに直感的に理解できました。スレッドの実装にも魅了されていますが、他の並行性アプローチと比べた潜在的な利点・コストを考えるほどの知識はありません。

言語の名前は、ガチョウが編隊を組んで飛ぶ様子に触発されたのでしょうか。後続の鳥は先頭の鳥の空気力学的な影の中を飛ぶことでエネルギーを節約し、必要に応じて交代するという。もしそうなら、メモリ管理モデルのとても素敵なメタファーですね。

ドキュメントにも感銘を受けました。AI生成のドキュメントは凡庸になりがちですが、作者は明らかに読みやすくするために時間を投資しており、設計判断の関連性と根拠が、好奇心旺盛なプログラマーがなぜ特定の方法で実装されているのかを理解するために必要な文脈を提供しています。

シンプルなアルゴリズムの定理から小さなゲームまで、詳細なサンプルが本当にありがたかったです。繰り返しますが、他の言語と比較して評価する経験はありませんが、コードの読みやすさとタスクフローの追いやすさに感銘を受けました。クラスについて考えなくて済むのはいつもプラスです！

とにかく、私は通常、新しい言語の提案には冷静に接します […]

Gooseはかなりクールです。考え方は、すべてのプログラムを表現可能にする必要はなく、制限された目的のための言語でも良いというものです。成長可能なメモリ領域の数を静的に指定できれば、Gooseを使えます。ただし、ガベージコレクションがないため、プログラム実行中のメモリ使用には注意が必要でしょう。つまり、古いデータが使われなくなっても、スタックを成長させ続けると大きくなりすぎる可能性があります。

それでも、データ指向アプリケーションのような多くのプログラムには適しているでしょう。古いメモリを再利用する限り、エンティティ・コンポーネント型のゲームシステムでもうまく機能するかもしれません…

これはwasmの世界ではどう動くのでしょうか？文脈（wasm、どこで、どうやって、どの実装か）を省いた雑な質問ですが、私の単純な理解では、wasmのほとんどはブラウザで動作する32ビットです。これが機能するには、真の仮想64ビット（または48ビット）アドレス空間が必要です。ホストであるブラウザなどが提供するかもしれませんが…。

ホストがgooseでコンパイルされた複数の.wasmをロードする必要がある場合、それらを別々の（ブラウザ）インスタンスで実行する必要もあるでしょう（あるいはwasmのデフォルトがそうなのかもしれませんが、確信はありません）。

ただ考えたのは、この言語は本質的にシングルスレッドでスレッド間通信（Dart用語で「isolates」）を行うため、JavaScriptワーカーへの変換に適しており、ブラウザに最適だということです。あとはメモリレイアウトだけが問題です。