Guileじゃなくて、他のSchemeの実装ってこと？Scheme間での移植はそんなに難しくないことが多いよ。特に、標準のR6RSやR7RSのライブラリ構文を使えばね。

Guileにはたくさんのライブラリがあるし、Guixの言語でもあるから、みんなが自分のものをGuix経由でパッケージ化する可能性が高いよね。Guix自体がエコシステムを豊かにしてるし、GuileプロジェクトはGuixを使って再現性を持たせることができる。ただ、いくつかの問題は残ってる。良いデバッガー、良いマクロ展開器（Emacsのgeiserはなんとか展開できるけど）、R6RSのライブラリ構文や標準ライブラリのバインディングの問題を解決することが思い浮かぶかな。Racketのマルチコア機能は長い間、ほとんどが重かった（場所を使ったり、まるで新しいRacket VMを立ち上げるみたいな）。ただ、futureの実装はあったけど、あれはいつも役に立つわけじゃなかった。最近Racketの状況は改善されたと思うけど、Guileのファイバーやfuture（Racketのfutureとは違う）と同じくらい良いかはわからないな。

AIファーストのプログラミング言語がどんなものになるかずっと考えてたんだけど、最も近いのはScheme/Lispみたいな感じかな。長い目で見れば、もっと人気が出るかもしれないね。

Guileが注目されてるのは嬉しいけど、Racketを軽視するのは良くないと思う。いくつかの考えを... * 最近のGuileのWASMに関する取り組みは期待できるね。（Racket関連のコンパイラでのJens Axel Soegaardの最近のWASMに関する仕事も注目だよ。） * RacketがChezの上に再ホスティングするのは良いアイデアだと思うし、Racketの内部は今やGuileより扱いやすいんじゃないかな。 * Racketは素晴らしい仕事をたくさんしてきたし、就職のキーワードを気にせずにツールを選べる人にはいいプラットフォームだと思う。広く受け入れられるチャンスがあったときにいくつかのミスを犯したし、業界の著名な貢献者が何人か去ってしまった。 * Racketは今でも最高のメタプログラミング機能を持っていると思う。ただ、syntax-parseや#langよりも、Guileや他のSchemeから本当に欲しいのはRacketのモジュールシステムのサポートだね。（Racketのサブモジュールをインラインで定義できるのが好きなんだ。埋め込みユニットテストや埋め込みAPIドキュメントのためにね。） * 現在、Schemeはテックブロやプログラマーの面接を受けなくていい人たちのためのものになっている。プロフェッショナリズムの面でこの分野はしばらく悪い状態だったし、経済の問題（そしておなじみのVC成長投資詐欺のポストZIRPの混乱）や「AI」ロボ盗作への押し付け（新しい投資詐欺も伴って）で、ICにとってさらに悪化しているね。

特にGuileはRacketのパフォーマンスに大きく遅れをとっている へぇ、俺の経験とは逆だな。これに反するベンチマークがたくさんあるのを見たから、理由を調べる努力をしないといけないかも。もしかしたら俺が単に間違ってるだけかもしれないし... でも、予想するに、GuileはRacketのスタートアップ時間のペナルティがないし、俺がやることのほとんどはIOに依存しているから、GuileのIOの方がRacketより良いと思う。

Racketに分裂があったなんて知らなかった。これはCSとBCバックエンドのこと？それはもう過去のことだと思ってたけど。

Racketはあまり追ってないけど、数年前にコミュニティ内のかなり重要な貢献者が、別のさらに重要な（おそらく基盤的な）貢献者に関するMissing Stair問題についてブログを書いていたのを覚えてる。俺は完全に外部の人間で、そのブログをもう見つけられないし、言語にも全然投資してないから、当時のやり取りについての結論を出すのはためらうけど、ああいう出来事の後にコミュニティが分裂するのは避けられないと思うな。

Guileは現在JITを持つバイトコードVMだけど、全体的にはChez/Racketには負けてるかな。でも、正直言ってかなり速いよ。スムーズに60fpsで動くゲームを作れるし、GCの停止もあまりない。成長の余地はたくさんあるけど、Guileは決して遅くはないよ。Gaucheは使ったことないけど、最近のGuileにはいいライブラリがたくさんあるね。

これは一番小さいREPLバイナリではないけど、見た中では一番大きいわけでもないよ。自分の経験から言うと、平均よりちょっと小さいか、中間くらいのサイズかな。ウェブサーバーの設定をgzip圧縮してないから、これを圧縮すべきだね。gzippedのrepl.wasmは339Kだよ。このバイナリはwasm-optも通してないしね。Hootは主に事前コンパイラで、インタプリタじゃないから、このREPLデモには本番用バイナリにはないマクロ展開器やランタイムモジュールシステム、インタプリタが含まれてる。余分なコードがかなりあるよ。ちなみに、別のリポジトリにtodoリストの例[0]があるから、そっちも見てみて。自分のマシンでは、todo.wasmは566Kの未圧縮、143Kのgzippedだよ。これにはSchemeで実装された仮想DOMの差分アルゴリズムも含まれてる。とはいえ、バイナリサイズを最適化する余地はかなりあるよ。例えば、関数内でローカル変数を生成しすぎてるのが分かってるから、追加のコンパイルパスで最適化できる部分が多いんだ。これがバイナリサイズに大きな影響を与えると思う。あと、実装時にWasmに欠けていた機能のせいで、バイナリサイズが増えてる部分もあるよ。継続のためのネイティブスタック切り替えがないのがその一例。スタック切り替えの提案を採用すれば、いくつかのバイトを削減できるはず。[0] https://codeberg.org/spritely/hoot-ffi-demo/ [1] https://codeberg.org/spritely/hoot/issues/193