世界を動かす技術を、日本語で。

Show HN: Wyzerプログラミング言語

2026年8月7日原文(github.com)

概要

Wyzer は、リソース指向・静的型付き・コンパイル型のプログラミング言語 Choreographic ProgrammingPerceusメモリモデル による分散安全性を実現 Rust の安全性を、よりシンプルな方法で分散システムにも拡張 一貫した所有権ルール でメモリ・スレッド・ネットワークを統一管理 コントリビューション やコミュニティ参加も歓迎

Wyzerとは何か

  • Wyzer :静的型付き・コンパイル型・リソース指向プログラミング言語
  • Choreographic Programming による分散安全性
  • Perceusメモリモデル による高速・単純なメモリ管理
  • 単一の所有権ルール でメモリ、スレッド、ネットワークを安全に管理
  • 分かりやすさ明示的な記述 を重視した設計

Wyzerを作る動機

  • Rust はプロセス内のメモリ安全性を保証
    • ただし、 分散デッドロックプロトコルミスマッチクロスサービス整合性 は保証しない
  • Wyzer はこれら分散システム特有の問題を Choreographic Programming で解決
  • 所有権ルール を統一的にネットワークや並列処理にも適用

Wyzerの特徴的な設計

  • Perceus方式参照カウント :KokaやLean 4から着想、Rustより単純なメモリ管理
  • Choreographic Programming :ネットワーク通信の安全性を型で保証し自動検証
  • 明示的なエラー処理 :例外ではなくResult型とmatch式で明示的に処理
  • 暗黙的な制御フロー排除 :async/awaitなどの分岐はなし、すべて型と所有権で表現

Wyzerの基本的な文法例

  • 変数と型
    • すべての値は明示的な型を持つ
    • デフォルトでイミュータブル、変更にはvarを使用
    • コンパイル時定数はconstで定義
fn main() {
    const MAX: u32 = 100;
    let x: u32 = 10;
    var y: u32 = 20;
    y = y + x;
    std::io::println(y);
}
  • 構造体とデータ
    • 独自のデータ構造を定義し、フィールドへ直接アクセス
struct Point { x: u32, y: u32 }
fn main() {
    let p: Point = Point { x: 10, y: 20 };
    std::io::println(p.x);
}
  • 制御フロー
    • if/else、while、forループをサポート
    • 条件式に括弧不要
fn main() {
    var i: u32 = 0;
    while i < 3 {
        std::io::println(i);
        i = i + 1;
    }
}
  • エラー処理とmatch
    • 失敗可能な関数はResult<T, E>を返す
    • match式でOkとErrを安全に処理
fn main() {
    let result: Result<u32, str> = Ok(42);
    match (result) {
        Ok(value) => std::io::println(value),
        Err(err_msg) => std::io::println(0)
    };
}

Wyzerのコアデザイン原則

  • 一つの書き方を徹底 :同じことを二通りで書ける場合は一方を排除
  • 隠れたマジックなし :重要な処理はコード上で見える形に
  • コンパイラに仕事を任せる :ただし複雑さが増す場合は明示的に
  • 未解決問題は正直に明示 :未完成部分は明確に記載

Wyzerのコアセマンティクス

  • メモリ管理 :基本は関数型、単一所有時はC並みの高速性
  • 所有権ルール :一度使ったリソースは再利用不可
  • ネットワーク安全性 :型で所有権を示し、コンパイラが通信ルールを検証
  • エラー処理 :例外ではなくResult型、非同期分岐も非採用

FAQ

  • WyzerはRustの発展版?
    • いいえ。Rustの安全性をより簡単な方法で実現、ネットワーク安全性も統合
  • Choreographic Programmingは新しい?
    • 数学的には確立済みだが、実用言語への応用は希少
  • なぜGCやasync/awaitを使わない?
    • Wyzerは一つの所有権ルールですべてを解決することを目指す
  • 完成度や実用性は?
    • まだ研究段階、未解決の課題あり
  • エレベーターピッチは?
    • メモリ・スレッド・ネットワークを一つの所有権ルールで安全管理。GCも複雑な借用チェッカーも不要

コントリビューションとコミュニティ

  • RESEARCH.md を参照し、貢献を歓迎
  • Discordサーバ で議論・参加可能
  • 公式ドキュメント やサンプルコードも用意
    • 例:donut.wyz(有名なドーナツ描画プログラム)

開発の背景と今後

  • プロジェクト開始の動機 :Rustの分散安全性不足への不満から
  • Wyzerの目標 :Choreographic Programmingを実用的な高水準言語へ
  • 所有権ルールとPerceus参照カウント で、LSPや開発ツールにも優しい設計
  • 5ヶ月の研究と数週間の開発 を経て、 バージョン0.1.0 リリース予定
  • 貢献者・コラボレーターを広く募集中

参考・名言

  • "Simplicity is not the absence of power. It is power without pretense." — Atiksh Sharma

まとめ

  • Wyzer は分散・並列・メモリ安全性を単一ルールで達成する新しい言語
  • Rust の安全性の良さを活かしつつ、より簡単で分散にも強い設計
  • コミュニティ・コントリビューション を重視したオープンな開発体制

Hackerたちの意見

あなたのREADMEやドキュメントには、ここでの面白いことやユニークなことが全然書かれてないよ。READMEではifについては触れてるけど、振付プログラミングやperceusについては何もなし。大事なリンクを見逃した?クールなところはどこ?

ちゃんとRESEARCH.md読んだよね? :)

まず第一に、構文がすごく一般的で保守的だね。これはめっちゃいいと思う。CとかTypeScript、Javaみたいに見えるし、謎のダイアクリティカルマークもないし。次に、もっと例が必要だな。READMEのドキュメントは永遠にスクロールできるけど、それはいいとして、言語がカバーしたい概念ごとに例を追加してほしい。この機会にしっかり考えて、READMEとその言語を驚くべきものにしてほしいな。そして、あなたのAIの免責事項(またはあなたのAIの免責事項)は意味があるね。

AIなしでドキュメントに取り組んでるよ。AIとの経験がひどかったからね。開発者がコミットメッセージを書く手助け以外は、AIの貢献を制限してる(AGENTS.mdを参照)。それもほとんど役に立たないけど、言語はまだ初期段階だし、いろいろ変わるかもしれない。

それと、例があるよ。donut.cを自分のプログラミング言語で再プログラムして、donut.wyzって呼んだんだ。https://github.com/rudywasfound/donut.wyz 見てみて!

一つ理解できないのは、どうやって分散デッドロックがないことを保証できるのかってこと。基礎研究でカバーされてると思うけど、概念的にはイメージしづらい。クレアがボブにメッセージを送って、ボブがアリスを待ってて、アリスがクレアを待ってるっていう振付はどうなるの?全ての有効なプログラムが受け入れられるわけじゃなくて、無効なプログラムは全て拒否されるっていうRustのメモリ安全性みたいな感じ?簡単な分散コードの実例と非トリビアルな例を見せる方が、3Dドーナツレンダリングよりも説得力があると思う。

これはプロトコルとして考えるといいよ。プロトコルは「クレアが送信」と「ボブが受信」を独立したアクションとして待ってるわけじゃなくて、グローバルなプログラム/状態の中で一つのコミュニケーションとして説明してる。コードに実行されるとき、送信は必ず受信に対応してるから、「クレアがボブに送信してる間にボブがアリスを待ってる」みたいなことは書けないんだ。プロトコル自体がその実行を許可してない限りね。だから、君が言ってるサイクルは同期の問題で偶然に現れることはないんだ。コミュニケーションは各ターンで正しく表現されてるって前提があるから。だから、確かに可能なプログラムのセットを制限してる気がする。すべてがこの方法でエンコードできるわけじゃないし、実際に解決するのも難しそうだね。Wyzerシステム間のコミュニケーションだけを許可するなら話は別だけど。実際のところはあまり詳しくないから、OPが一番詳しいと思う。実際にどう機能するのか、すごく興味があるよ。

この質問は、実際にこのパラダイムの研究の核心に関わるものです。まず、どのように機能するのかを説明し、その後に表現力の問題について触れます。振付プログラミング言語は、通信意図をプログラミングするための抽象を提供します。例えば、よくあるのは次のようなプリミティブです:Alice.expr -> Bob.x これは「アリスがexprの評価をボブに伝え、ボブがそのメッセージをローカル変数xに保存する」という意味です。(実際、私たちは、データ型をロケーションで拡張することで、どんな主流の言語にもこのような高レベルのプリミティブを追加できることを発見しました。詳細はchoral-lang.orgを参照してください。)これにより、ミスマッチした通信アクションを書くことが不可能になります。なぜなら、送信と受信のアクションを一つの原子的な命令で表現しているからです:構造的にうまく一致しています。次に、コンパイラ(通常は「プロジェクション」と呼ばれます)を構築し、アリスとボブのための分散プログラムを生成します。アリスがボブに送信し、ボブがアリスから受信するという形です。私たちはこれらのコンパイラの形式モデルを作り、それが正しいことを数学的に証明するのが好きです。振付に従ったコンパイラは、複雑なチェックなしにコンパイルされたコードのデッドロックフリーを自動的に保証します。なぜなら、ソースの振付は文法的にデッドロックした用語を表現できないからです。したがって、振付からコンパイルできるデッドロックした分散プログラムは存在しません。これは、「ガイドする」プログラミングのための高レベル言語を設計するという巧妙なトリックの応用です。低レベルのプリミティブを使って分散システムをプログラミングし、デッドロックをチェックするという非常に難しい作業を試みるのではなく、デッドロックが書けない(または少なくともチェックが容易な)高レベル言語を使います。これで振付プログラミングがどのように機能するかの直感が説明できたと思います。しかし、あなたがしたように、自然に次の質問が浮かびます:振付プログラミング言語で何を表現できるのか?根本的な制限はあるのか?まだ正確にはわかりませんが、これは非常に活発に探求されている分野です。年々、より多くのインタラクションパターンを捉える賢い振付プログラミング言語が開発されています。驚くべきことに、いくつかの分散言語の理論(またはインタラクションパターン)において、振付プログラミングが完全であることがわかっています。つまり、それはその理論でモデル化できるすべてのデッドロックフリーなシステムを捉えることができます。この種の最初の結果は、線形論理で記述できるすべてのインタラクションの振る舞いを捉えることに関するものでした(プロセス計算のカリー・ハワード解釈において)。しかし、再帰的な振る舞いやプロセスの生成(フォーク)にも対処できる研究もあります。これは励みになります。このパラダイムが正確に何ができて何ができないかを調査するのは面白いと思います(でも、ここはかなり偏っていますが…)。数学的にモデル化されたコンパイラを使うことで、生成されたコードを積極的に最適化できるからです(例えば、Ozoneのように非同期性を追加することなど)。現時点での最先端の状況を見る限り、振付プログラミングは多くの異なる目的に対して「十分に表現力がある」ようです。高レベルの抽象が一般的にそうであるように、ほとんどのケースやほとんどの人にとって、高レベル言語が良く、低レベルの通信アクションはニッチなシナリオでのみ必要になることを願っています。その間に、ミドルウェアや外部APIと統合できる振付言語もあって、欠点を補っています(ChoralやHasChorなど)。

うーん、分散システムは、接続されたすべてのシステムをコントロールできる限り、確率的な借用チェックの形式でモデル化できると思う。

あなたのこのMediumの投稿見たよ。https://medium.com/@atixwasfound/how-i-began-writing-my-own-... そこには、8歳の時にこの旅を始めて、14歳のプログラマーだって書いてあった。正直、これについてどう感じるかまだ整理できてない。

時間が経つのは早いね :) でもその前はもっと草が青かったし、懐かしいな!

14歳がこれをやったならすごいね、AIがあっても。

Hacker Newsで議論の続きを見る