■ 1. Wyzerの概要
- Wyzerの位置づけ:
- 新しいプログラミング言語であり、READMEに仕様と思想が記載されている
- 言語の4つの特徴:
- 静的型付けかつコンパイル型である
- 所有権ベースの設計によるリソース指向である
- choreographic programming(コレオグラフィックプログラミング)による分散安全性の統合である
- Perceusメモリモデルを採用している
■ 2. 開発の動機
- Rustの限界:
- Rustはプロセス内の安全性は保証するが、分散システムの問題は解決しない
- 未解決のまま残る分散システムの問題:
- 分散デッドロック
- プロトコルの不一致
- サービス間の整合性エラー
- choreographic programmingの導入:
- 上記の問題を解決するために導入している
- 複数の参加者間の通信プロトコルを1つの振り付け(コレオグラフィ)として記述する手法である
- 記述したコレオグラフィから各participantのコードを自動生成する
■ 3. 技術的な新規性
- 新規性の所在:
- 既存の要素を新しい組み合わせ方で統合している点にある
- 各要素の由来:
- Perceus参照カウントはKoka、Lean 4から着想を得ている
- Choreographic programmingは学術研究から着想を得ている
- 独自の点:
- コレオグラフィの考え方は通常ネットワーク通信にのみ使われる
- その考え方をメモリ管理、スレッド、割り込み処理にまで同じルールで適用しようとしている
- 核心コンセプト:
- 1つの所有権ルールでメモリ、並行性、ネットワークすべての安全性を証明する
■ 4. 言語仕様
- 変数の可変性:
- 変数は
letによりデフォルトでイミュータブルである- 可変にする場合は
varを明示する- 定数定義:
constでコンパイル時定数を定義する- データ構造:
structでデータ構造を定義しフィールドに直接アクセスする- 制御構文:
- if/else、while、forをサポートする
- 条件式に括弧は不要である
- エラー処理:
Result<T, E>型とmatch式で明示的に行う- 隠れた例外や
async/awaitの分離は存在しない■ 5. 設計思想
- 書き方の一意性:
- 同じことをする書き方は1つだけという原則を採る
- TIMTOWTDIの逆にあたる考え方である
- 明示と省力化の両立:
- 重要な処理は隠さない
- 余計なボイラープレートは書かせない
- コンパイラへの委譲方針:
- コンパイラに任せられる部分は任せる
- 曖昧さが生じる場合は明示ルールを要求する
- 課題の開示:
- 未解決の課題は正直に開示する
■ 6. 現状と位置づけ
- 初期段階の研究プロジェクト:
- FAQセクションで作者自身が初期段階の研究プロジェクトであると明言している
- 本番運用可能かという問いに対し、多くの大きな課題が未解決であると正直に述べている
- Rustとの関係:
- Rustの代替ではない
- Rustの安全性を学習コストを抑えつつネットワーク領域にも拡張できるかという実験的な試みである
- AIの利用範囲:
- コミットメッセージ生成に使用した
- choreographic programmingやPerceusモデルの調査に使用した
- ロゴデザインの発想補助に使用した
■ 1. 問題設定の妥当性
- 所有権の不明確さという診断:
- 所有権が不明確であることがメモリバグ、デッドロック、ネットワークエラーに共通する根本原因であるという診断は筋が通る
- Rustからの発想の拡張:
- Rustの所有権モデルがメモリ安全性で成功した実績を踏まえれば、同種のロジックを他領域に拡張する発想自体は理にかなう
■ 2. Perceus選択の堅実さ
- GCと借用チェッカーの中間解:
- GC任せにせず、かつRustの借用チェッカーほど複雑でない中間解として現実的な判断
- Koka、Lean 4で実証済みのPerceus参照カウントを採用している
- 関数型記述と破壊的更新の両立:
- 関数型的に書き、単一所有時はコンパイラが破壊的更新に変換するアプローチ
- 学習コストと性能のバランスを取る妥当な選択
■ 3. Choreographic programmingの学術的蓄積
- 実在する研究領域:
- 思いつきではなく、Pict、Chor、HasChorなど実際に学術的蓄積のある分野
- 現状認識の正確さ:
- 研究止まりで実用言語に持ち込まれていないという現状認識は正確
- そこにギャップを見出す動機は妥当
■ 4. 単一ルールでの全領域解決への疑問
- 数学的構造と実務要求の乖離:
- メモリ安全性、並行性安全性、ネットワーク安全性は数学的には線形/アフィン型という似た構造を持つ
- 実務上の要求は大きく異なる
- メモリの性質:
- 単一プロセス内、ミリ秒単位、失敗コストは低い
- ネットワークの性質:
- プロセス間、秒〜分単位で、部分的失敗が常態
- タイムアウト、再送、片方だけクラッシュといった事象が起こる
- コレオグラフィ理論の理想化:
- メッセージは必ず届く、参加者はクラッシュしないといった理想化を前提にしがち
- 実ネットワークの非同期性、部分的故障を所有権ルール一本でどう扱うかはREADME内で具体化されていない
- 言うは易く行うは難しの核心部分と思われる
■ 5. 型シグネチャによる見える化の不明確さ
- 主張と実例の乖離:
- 型を見ればネットワークプロトコルがわかるとあるが、実際のコード例はstruct Point程度でこの機能が全く示されていない
- 分散プロトコルの型表現の難しさ:
- セッション型研究でも複雑化しやすい部分
- 具体的シンタックスがないと評価しづらい
■ 6. スレッド、割り込み拡張の説明不足
- 割り込み安全性の証明という主張:
- 同じルールで割り込み安全性も証明するという主張は野心的
- コレオグラフィとの相性:
- 割り込みは典型的に非同期かつプリエンプティブ
- あらかじめ決まった振り付けという発想と相性が悪いように見える
- 判断材料の不足:
- 詳細はRESEARCH.md側にあるかもしれないが、それなしには判断が難しい
■ 7. Rustより簡単との根拠の薄さ
- Perceus採用が寄与する範囲:
- 借用チェッカーを避けてPerceusにする点は性能と学習コストに寄与する
- 線形性ルールの全面適用:
- 所有権は一度使ったら二度と使えないというRust同様、むしろより厳格な線形性ルールを持つ
- これをメモリ、ネットワーク、スレッドに全面適用するなら、学習曲線がRustより緩やかになる保証はない
- 表面文法と学習コストの本質:
- let、var、matchといった表面文法は平易
- それはRustの学習コストの本質である借用、ライフタイム推論とは別問題
■ 8. 総評
- 方向性の正当性:
- 所有権を分散システムまで統一的に拡張するコンセプトの方向性は学術的にも興味深い
- 正当な研究テーマである
- README単体での不足:
- 1ルールで3領域を統一するという理論的主張の具体的メカニズムが提示されていない
- コード例が基礎文法止まりで、型からプロトコルが読める、割り込み安全性といった核心を実証していない
- 分散システム特有の部分的故障、非同期性への対処が語られていない
- 現時点での位置づけ:
- 作者自身が早期の研究段階、大きな課題が未解決と認めている
- 現時点ではビジョン表明であり、設計の実現可能性はRESEARCH.mdや形式仕様を見ないと判断できないというのが公平な評価