Rustベースの夢の言語「Gossamer」登場！本物のゴルーチンと停止なしGCを実現

Rustの書き味に、Goの強力な並行処理機能が融合したら？「Gossamer」は、Rustライクな構文を持ちつつ、本物のゴルーチン（goroutines）をサポートし、さらにGCによる停止（pause-free memory）がないメモリ管理を実現した注目の新言語です。並行処理のパフォーマンスとメモリ安全性を高次元で両立させたいエンジニアは必見です。

Gossamerにはサイクルコレクターと先行的な参照カウント機能があるな。1万ノードのグラフ、特に循環があるような場合の最後の参照を解放するなんて、うまくいくわけないよ。つまり「ポーズフリー」なメモリ管理じゃないってこと。もしポーズフリーな環境が欲しいなら、ZGCやその他のモダンなVM上の最新GCを使うべきだ。

過去30年の自動メモリ管理の研究を無視した言語が最近やたらと出ているが、正直言って真面目に取り合う気になれない。目の前にオープンソースのポーズレスなGCの奇跡がいくつもあるのに、わざわざメモリ管理をユーザーに押し付けるのが言語設計のトレンドだなんてどうかしてる。

優れたGCが欲しいなら、わざわざ巨大なVMを使う必要すらない。MPSを使えばいい。自分でVMを実装したい場合でも、選択肢はいくらでもあるだろ。

悪いけど、フランス語でその名前は「苦い子供（bitterkid）」って意味なんだよね。どうしても笑っちゃうんだけど :D

昔はこういうページを見ると「おっ、ウェブサイトがこれだけ洗練されてるなら素晴らしいプロジェクトに違いない」と思ったものだ。

今となっては、ニュートラルか、むしろ少しマイナスのシグナルにすら感じる（特にページの一行目にダッシュ記号が入ってるあたり）。

これが本当に注目に値するプロジェクトなのか、それとも今のあふれかえった粗製濫造プロジェクトの単なる一つなのか、誰か教えてくれないか？

M:Nスケジューリングを使った真のゴルーチン（軽量スレッドやファイバー）を採用する言語が増えているのは嬉しいね。[編集: 軽量スレッドやファイバーのこと]。もっと増えてもいいのに。コンパイル言語だと、パッと思いつくのはGoとCrystalくらいかな。

Gossamerに興味があるなら、RustライクでGoにコンパイルされるLisも面白いかもしれないよ： https://github.com/ivov/lisette (https://github.com/ivov/lisette)

READMEによると：

• 安全で表現力が高い:

  • Hindley-Milner型システム
  • 代数的データ型、パターンマッチング
  • 式指向、デフォルトでイミュータブル
  • Rust風の構文、|>演算子、tryブロック
  • Goスタイルのインターフェース、チャネル、ゴルーチン

• 実用重視:

  • Goエコシステムとの相互運用性 (開発中)
  • リンター、フォーマッター、250以上の診断機能
  • 高速なインクリメンタルコンパイル、読みやすいGoコード出力
  • VSCode, Neovim, Zed, Helix, GoLand向けのLSP対応

最後のPythonの例とコードスニペットの挙動が一致してないと思うんだけど。

names = sorted({name.lower() for name in users if name})

対してこれ：

let names = users
    |> iter::filter(|n: String| n.len() > 0)
    |> iter::map(|n: String| n.to_lower())
    |> iter::sort_by_key(|n: String| n.len())

Pythonはセット（ユニークな値のみ）をソートしてるけど、Gossamerの方にはユニーク化やセットを使うアプローチが見当たらない気がするんだよね。

まだ2ヶ月のプロジェクトだろ。明らかにAI生成っぽい（vibe coded）な。とはいえ、今やこんなものまでAIに書かせられるのはすごいことだよ。

言語設計自体はかなり良さそうだし、埋め込み可能で（しかもAI任せじゃない）こういう言語があったらぜひ使いたい。簡単に埋め込める良い言語なんてほぼ皆無だしね。みんなLua使ってるけど、あれはひどいもんだ。

goとspawnの両方を用意する意味がわからないな。spawnは一般的なスレッド生成メカニズムのようで、join可能なハンドルを生成する（キャンセルはできるのか？仕様書を確認したが確証は持てない）。一方でgoはゴルーチンの欠点をそのまま引き継いでいる。joinもできないしキャンセルもできないから、それを実現するために自分でインフラを構築しなきゃいけない。Goが17年前に登場した当時は洗練されていたかもしれないが、これは今でも言語の大きな弱点であって、コミュニティはそれをカバーするための慣習（今ではGoの標準ライブラリや特定のパターンとして標準化されている）を開発せざるを得なかった。なぜ中途半端に直して（spawnを入れることで）、それでも元の問題を放置したのか理解できない。spawnのハンドルを無視できるようにして、その罠を排除すればよかったんだ。無視するかどうかを選択制にすれば、プログラマが自分の足元を撃つ選択をすることにはなるが、少なくとも設計上の押し付けにはならないだろ。

https://gossamer-lang.org/docs/migration/rust/ (https://gossamer-lang.org/docs/migration/rust/) を見て気になった点が3つある。

• ユーザー定義マクロが全くない。println!ファミリのようなマクロがパース時に展開される仕組みしかない。Rustにおいてメタプログラミングは非常に重要なのに。

• （unsafeが）言語レベルで禁止されている。ソースコードにunsafeキーワードがない。標準ライブラリも安全なRustで書かれている。……これじゃ低レイヤープログラミングは無理だな。

• ムーブセマンティクスがない。非自明な値はヒープ割り当てされて参照カウントされ、参照共有される。プリミティブはRustと同じくコピーされる。これまた、低レイヤープログラミングには向かない。

これで「Rust風味（あるいはシステムプログラミング言語）」と呼ぶのは、かなり強気すぎる気がするな。

この投稿を見てSwiftを思い出したよ。自動参照カウント（ARC）を採用したモダンで高性能な言語だ。REPLもあるしLLVM経由でコンパイルする。ゴルーチンと引き換えに、もう少し安全性が組み込まれている感じだね。