【Show HN】Rustの不満を解消！分散システムの安全性を追求した新言語「Wyzer」を開発した話

数ヶ月前から取り組んでいたプロジェクト「Wyzer（より賢く、という願いを込めて）」をついに公開します。Wyzerは静的型付け、コンパイル言語であり、リソース指向のプログラミング言語です。最大の特長は、コレオグラフィック・プログラミング（choreographic programming）による統合された分散安全性の確保と、Perceusメモリモデルの採用にあります。このプロジェクトを始めたきっかけは、Rustに対するフラストレーションでした。Rustは厳格な型チェックによってメモリ安全性を保証してくれますが、分散システムにおけるデッドロック（複数のノードやサービスが相互にリソースを待ち続け、循環参照が発生する状態）に対する安全性までは保証してくれません。また、サービス間における正確性やプロトコルの不一致といった課題も残されています。Wyzerは、これら安全性のアプローチが欠けている領域を解決するため、コレオグラフィック・プログラミングの概念を高級言語へ汎用的に落とし込むことに注力しました。Borrow checkerやLifetimeの代わりに、線形型（Linear/Affine types）とPerceus参照カウントを採用しており、これらはLSP（Language Server Protocol）にとっても理解がはるかに容易です。5ヶ月のリサーチと数週間の開発を経て、まもなくバージョン0.1.0をリリース予定です。コントリビューターも絶賛募集中ですので、興味のある方はぜひ参加してください！

READMEやドキュメントに、ここでの興味深かったりユニークだったりする要素が何一つ書かれていないよ。if文についてはREADMEで触れているのに、コレオグラフィック・プログラミングやPerceusについてはノータッチだ。何か重要なリンクを見逃してるかな？一番面白いところはどこにあるの？

まず、構文がすごく汎用的で保守的なのは最高だね。これについては大賛成。CやTypeScript、Javaみたいに見えて、変な記号がごちゃごちゃしてないのがいい。

次に、もっとサンプルが欲しい。READMEはいくら長くても構わないから、この言語がカバーしようとしている概念すべてに対して例を追加してほしい。これは自分の考えを整理して、READMEと言語を驚くべきものにするチャンスだよ。

それと、AIについてのディスクレーマー（あるいは君のAIのディスクレーマー）は納得感があるね。

理解できないことが一つあって、分散デッドロックが発生しないことをどうやって保証しているのかってことなんだ。元になっている研究ではカバーされているんだろうけど、概念的に想像するのが難しくて。

ClaireがBobにメッセージを送るけど、BobはAliceを待っていて、AliceはClaireを待っている…といった状況をどうやって防ぐのかな？

Rustのメモリ安全性みたいに、有効なプログラムはすべて受け入れるけど、無効なプログラムはすべて拒否するような仕組みなのかな？

3Dドーナツのレンダリングより、些細なものからそうでないものまで、実際の分散コードの例を見せてくれたほうがずっと説得力があると思う。

君のMediumの記事（https://medium.com/@atixwasfound/how-i-began-writing-my-own-programming-language-01a1672d3bd8 ）を読んだよ。

8歳からこの旅を始めて、今は14歳のプログラマーなんだね。

正直なところ、どう受け止めたらいいか分からないな。ちょっと整理させてほしい。

この野心は大好きだし、よくある「2015年の最先端」をなぞっただけの言語じゃないのがいい。純粋に違う何かをやろうとしているね。「学術界からネタを拾って実際に動くものにする」という分野は、まだ十分に開拓されていない豊かな領域だよ。

ただ、古い言い回しを使うなら、君の才能が宝の持ち腐れになっているよ。何が本当に新しいのかを探し出すために、掘り下げる必要がある。ドキュメント全体を再構築して、新しい部分に焦点を当てることをお勧めするよ。HNの住人は構文例が最初に見えないと文句を言うことが多いけれど、君の場合は、とにかく「コレオグラフィ」のアイデアを最初に提示すべきだ。

言語構造上、アトミックに安全であることが保証された、並行リモートカウンターのような単純な例を立てて、すぐにそれが何を意味するのかを解説してみて。ありふれた言語構文の説明は後回しでいいから、核心となる部分にいきなり飛び込むんだ。docsディレクトリを見ると、コレオグラフィの説明を1〜8章の解説より前に持ってくるのはプログラマーとしての直感に反するのかもしれないけれど、コレオグラフィで読者の興味を惹きつけられれば、残りの部分は後で読んでくれるはずだよ。最初から細かいところを読ませようとしても、離脱されるだけだからね。

プログラムレベルで世界を統一的に捉え、サーバーやクライアント（あるいは他の役割）として別々の実行ファイルを生成する、この現代的なアプローチはすごくイケてる。もっと前面に押し出そう。

コレオグラフィについての分かりやすい入門書を探している人は、これを見てみるといいよ：https://decomposition.al/zines/communicating-chorrectly-zine.pdf

残念ながら、GitHubのREADMEにはWyzerのコレオグラフィ的な側面がどう動作するのか、あるいはどんな見た目なのかが説明されていないのが惜しい（ざっと見た感じで見つけられなかったんだけど、間違っていたら指摘してね）。

おっ、コレオグラフィック・プログラミング（https://github.com/Wyzer-Lang/wyzer/blob/master/docs/08_choreography.md ）って、Next.jsやDioxus、Leptosで実装されている「サーバー関数」にすごく似ているね。それを言語機能として汎用化したような感じか。

間違いなく面白いアイデアだね。言語機能として取り込む価値があるかどうかは、時間が経てば分かるだろう。

メモリ（第5章）：データを変更しない関数型コードを書く。舞台裏では、データの所有者が一人だけの場合、コンパイラがメモリ上で直接書き換える。これにより、ガベージコレクターやライフタイムルールなしでC言語並みの速さを実現している。

データの所有者が複数いる場合はどうなるの？デバッグが難しいような突発的なパフォーマンスのバグが発生したりしないかな？

この構成はすごく評価するよ：

1. Wyzerとは何か（1段落で）

2. なぜ新しい言語を作るのか？

HNのプロジェクトを見ていると、ちらっと見ただけでは「何がしたいのか」がさっぱり分からないものがあまりにも多い。これは明確で簡潔だね。

「すべてのコンピュータのためのコードを生成するネットワークルールを1つ書く」というアプローチの課題は、すべてのコンピュータで同じ言語を動かすのが難しいことだ。例えばWebアプリケーションなら、Javascriptにトランスパイルするか、WASMをターゲットにする必要があるよね。（ちなみにWASMはJavascriptと比べるとオーバーヘッドが大きいんだ）

難しい問題に挑戦している言語だね、おめでとう。

ただ…関数呼び出しが「内部」なのか「外部」なのかがほとんど隠されているのは少し気になる。
個人的にはあんまり好きじゃないかな。

1. 両者の操作にはレイテンシに大きな差があるから、外部呼び出しの回数は最小限にしたい
2. 外部関数呼び出しでタイムアウトが発生したときはどうなるの？
   ドキュメントで見当たらなかったんだけど、見落としてるかな？