10 ポイント 投稿者 GN⁺ 2025-11-27 | 1件のコメント | WhatsAppで共有
  • Unison は、コード定義を 名前ではなく内容(Hash) で識別する仕組みに基づき、コードの保存・バージョン管理・デプロイの方法全体を新しく再構成した 関数型プログラミング言語
  • すべてのコードはテキストファイルではなく コードベース(DB) に保存され、名前は単なるラベルとして扱われるため、同名/ファイル衝突・リファクタリング衝突 のような問題が構造的に解消される
  • UCM(Unison Codebase Manager)を通じて 定義の追加・削除・移動・リネーム・テスト・実行 が行われ、LSP・UCM Desktop・Unison Share と連携した コラボレーションツールのエコシステム が提供される
  • Abilities ベースの エフェクトシステム、遅延計算、構造的パターンマッチングなどの言語機能に加え、同一プログラム内で アプリケーションロジックとクラウドデプロイ(Cloud/BYOC) を一緒に定義する統合モデルへと拡張されている
  • ハッシュベースの構造により、重複コンパイルの排除・バージョン衝突の低減・静的参照探索 などが基本特性となり、Share・Cloud・Projects・Branch システムを含む 一貫した分散開発体験 を提供する

Unison 言語概要

  • 内容ベース識別(content-addressable code) 構造で定義を管理し、同じ名前でも内容が異なれば完全に別個の定義として扱われる
    • 再コンパイル不要、API 進化時の衝突を最小化、完全な参照安定性
  • コードベースは SQLite ベースの DB として維持され、コード・名前・ドキュメントがすべてデータとして保存される
    • lsview のような UCM コマンドで構造を探索
  • テキストファイルは編集のためのインターフェースにすぎず、実際のソースの唯一の正本は DB である
    • 名前衝突・ファイルマージ衝突・リポジトリ構造管理はすべて旧来的な概念へと縮小される

言語機能

  • Abilities: IO、Exception などのエフェクトを型システムで制御する機能
  • 構造的パターンマッチング: 型を構造的に分解して制御フローを構成
  • 遅延計算(Delayed computations): 非正格評価を明示的に表現
  • 強力な静的型付け + 豊富な型推論 + Kind-checking を提供

開発環境とツールチェーン

  • UCM(Unison Codebase Manager)
    • 定義の作成・削除・リネーム・テスト・実行
    • プロジェクト・ブランチ・クローン・マージなどの Git ライクなバージョン管理 を言語に内蔵
  • UCM Desktop
    • コードベース構造の探索、クリックベースの定義移動、ドキュメントレンダリング
  • LSP サポート
    • 人気のあるエディタの大半で IDE 機能を利用可能
  • Unison Share
    • 中央コードハブ: プロジェクトのホスティング、検索、レビュー、貢献(= Pull Request)、型ベース検索
    • すべての定義が hash ベースであるため、参照は常にハイパーリンクのように移動可能

デプロイモデル: Unison Cloud & BYOC

  • 同じ言語で アプリケーションロジック + インフラ定義 まで記述し、そのままデプロイ可能
  • YAML、Helm、複雑な RPC 規約なしに「コード」だけで分散システムを構成
  • BYOC(Bring Your Own Cloud)により、自前のコンテナインフラ上でも Cloud スタックを実行可能
  • OrderedTable などの 型安全なストレージ、Daemon サポート、自動オーケストレーションを含む

例: Guessing Game

  • Abilities(IO、Exception)を活用したシンプルな CLI 例
  • Random、コンソール IO、パターンマッチング、遅延計算などの言語要素が自然に組み合わさった形

エコシステムとコミュニティ

  • Share を通じた 貢献・レビュー・組織アカウント をサポート
  • 型ベースでエコシステム全体を検索でき、AI エージェント向けの MCP サーバー を提供
  • 段階的に C FFI の作業を進行中
  • Git-style diff ビューア、ブランチ注釈などコラボレーション生産性機能を拡張

主な歴史(要約)

  • 2018: Unison Computing 設立
  • 2019: 最初のアルファリリース
  • 2021: コードベースを SQLite に移行(100x 縮小)
  • 2021: Unison Share 公開
  • 2022~2024: LSP、Projects、Kind-checking、Pull Request、Cloud GA
  • 2025: Desktop App、大規模ランタイム最適化、MCP サーバー、BYOC サポート
  • 2025 Nov: Unison 1.0 正式リリース

FAQ

  • なぜ新しい言語なのか?
    • ハッシュベースのコードモデルは、既存言語に アドオンの形で移植するのがほぼ不可能 に近い
    • コード保存・バージョン管理・デプロイ・コラボレーションの方法がすべてこのアイデアから自然に派生するため、最初から新言語として設計 する必要があった
  • 実際の利用事例は?
    • Unison Cloud 全体が Unison 自身で書かれて 運用されている
    • 組織・チーム単位のコラボレーションと分散アプリケーション開発のための商用レベルのワークフローを構成
  • ベンダーロックインへの懸念: オープンソース言語であり、Docker などで自由にデプロイ可能で BYOC もサポート
  • コラボレーション方式: 組織、チケット、コードレビュー、PR などをサポートし、定義単位でのみ衝突が発生
  • バージョン管理: Git なしで独自のプロジェクト・ブランチ・プッシュ・プル・マージ機能を提供
  • IDE の制約なし: LSP サーバーの提供により多様なエディタを利用可能
  • 他言語連携: C FFI を開発中
  • ファイルなしコードベースへのアクセス: CLI(UCM)コマンドまたは Desktop アプリで構造を探索可能

1件のコメント

 
GN⁺ 2025-11-27
Hacker Newsの意見
  • 私は Unison をかなり昔から追いかけてきた。Paulの個人ブログ時代からなので、もう10年以上になる。今回の1.0リリースは本当に大きな節目だが、正直少しがっかりもしている
    私はプログラミング言語が本当に好きで、Rust、Go、Zigのような言語の成長もずっと見てきたが、Unisonはこの完成度の高さの割に エコシステムの広がり が弱いと感じる
    その理由は、機能の大半が クラウド依存 に設計されたビジネスモデルにあると思う。BYOCオプションはあるが十分ではない。何か雰囲気が噛み合っていない

    • Zig、Rust、Goと比較するのには同意しない。Unisonは Abilitiesデータベースベースのコード構造 のような「新しくて変わった」概念をあまりに早く使い切ってしまう
      Shareプロジェクトはオープンソースで、GitHubにも実質的な依存はあるのに今なお人気がある。
      こうした点を否定したいわけではなく、実際に触ってみて、他の言語設計にも役立つ部分を感じてほしい
    • Unisonの問題は FFIの不在 だと思う。むしろビジネスに集中するのは良い戦略だ。収益があれば、ユーザーにとって重要な機能に集中でき、些細な議論に巻き込まれずに済む
    • 私も同意する。インターネットが切れても ローカル協調 が可能なシステムを作りたいのだが、ハッシュベースの関数構造はまさにそれに合っている。
      ただ、学習資料の大半がクラウドインフラの利用を前提にしているので、オフライン環境では行き止まりになってしまう。
      おそらくUnison流のやり方はあるのだろうが、マーケティングレイヤー がその道を隠してしまっている
    • 商業的な方向性があるのはむしろ歓迎だ。うまくいけば、より多くの時間を投入して 持続可能な発展 を実現できる。
      有料ユーザーが増えれば、技術を現実的で実用的なものに保とうとする動機にもなる。
      商業的要素がなければ、ただのもう一つの esolang に感じられただろう。これでサイドプロジェクトに使ってみる気になった
    • 中核のアイデアは素晴らしいが、コードの配布や取得が クラウドプラットフォーム 経由でしかできないなら、たぶん使わないと思う。
      ドキュメントにはUnison Shareへの言及があるが、これも unison-lang.org でホストされている。
      BYOCオプションはあるが、それでも unison.cloud のアカウントとサブスクリプションが必要だ。こうした点はマーケティングやドキュメントで明確にしてほしい
  • こんにちは、私はUnison言語の 共同制作者 の一人です。気になることがあれば何でも聞いてください

    • 長いことUnisonを見てきたので、リリースおめでとう!
      Unisonは algebraic effects (Abilities) を主要機能として打ち出した最初期の言語の一つだ。
      初期にはこの機能がうまく受け入れられるか確信がなかったと記憶しているが、今は満足しているのか気になる。
      効果システムが言語の他の部分とうまく調和しているか、構文は気に入っているか、内部実装にまつわる面白い話も聞いてみたい
      関連ドキュメント: Unison Abilities
    • テスト実行結果をキャッシュするとき、実際にはどのデータを保存しているのか気になる。
      式のハッシュと "passed" の値だけを保存するのか、それとも すべての値のハッシュ を計算できるのかも知りたい。
      もし後者なら、NixやTrustixのような 再現可能ビルド を拡張できそうだ。
      おそらく現状のキャッシュは束縛された式だけを扱うのだろうが、ランタイムで外界とつながる橋の役割も果たせるかもしれない
    • リリースおめでとう! Unisonの ハッシュベース定義 の概念は本当に革新的だ。
      ただ、今のところは問題を探している解決策のようにも感じる。
      この言語は誰を対象にしていて、Unison Cloud以外に実際の本番環境で使っているところがあるのかも気になる
    • 本当に素晴らしいプロジェクトだ。ただ、content-addressed language という概念がまだ完全には理解できていない。
      最初はBEAMベースの言語だと思っていたが、独自VM上で動作するのだね。
      BEAM言語と比べて fault tolerance の面でどう違うのか、そしてUnisonのほうが向いているユースケースは何か知りたい
    • OrderedTableTable のような永続化プリミティブが内部的にどう実装されているのか気になる。
      外部データベースを呼び出しているのか、それともUnison自体で実装されているのか知りたい。
      Database抽象化と合わせて見ると本当に興味深い組み合わせだが、概念を完全に理解するのは簡単ではない
  • 私は Unison を最も興味深い言語の一つだと思っている。
    algebraic effects は次世代の中核概念になると信じている。
    Unisonにはこのほかにも面白いアイデアが多い。
    個人的には ゲームのモッド開発 にも向いていそうだ。
    信頼できないコードをクライアント側で実行する必要があるが、Unisonの abilityシステム のおかげでサンドボックス環境を簡単に作れそうだ。
    また ECS(Entity Component System) の実装にも役立つかもしれない。
    関数が必要とする能力を推論できるなら、並列実行の安全性を自動的に確保できるはずだ

    • 実際にUnison Cloudではこの サンドボックス検証 を行っている。
      CloudではIO abilityを直接使うことはできず、代わりに安全に制御された Http ability のようなものだけが許可される。
      こうすることで、ユーザーがファイルシステムにアクセスできないようにしている。
      私もこの機能をゲーム開発に活用することを構想中だ。
      別のユーザーが native service としてabilityを実装し、ゲームに貢献することもできる。
      参考リンク: Unison Cloud, validateSandboxedコード, ECS例
  • このプロジェクトを初めて見たとき、「5年後にはどうなっているだろう」と思ったが、本当にそれだけの時間が過ぎた。
    今こうして 1.0リリース を見られて本当にうれしい

  • こういう 急進的な言語 を実際の産業環境でも使えるものにしたのは大きな成果だ。おめでとう

  • 私はUnisonのようなシステムこそ コンピューティングの未来 だと思っている。
    ただ、その未来がいつ来るのかは分からない。
    こうしたシステムの美しさは、インフラ、データ、サービス層が一つの統合されたシステムの中にあることだ。
    もしかすると AIコーディングエージェント にとっても、より良い基盤になるかもしれない。
    ただ、VCモデルよりも 持続可能な独立開発 のほうが向いているとも思う。
    このような長期プロジェクトを続けているチームは本当に素晴らしい

  • RúnarがUnisonを始めると言っていた日のことを覚えている。
    まったく新しいパラダイムを切り開くプロジェクトだと思っていたし、今こうして1.0リリースを見ると本当に誇らしい。
    いつかUnisonが私の メイン言語 になることを願っている

  • UnisonのWebサイトに ベンチマーク があるといいのにと思う。
    性能特性が分かれば、どんな用途に向いているのか感覚がつかめる。
    Django、Express.js、ASP.NETとの リクエスト処理速度の比較 のような簡単な数値だけでもあると助かる。
    アイデアは面白いが、Web以外のランタイムターゲットも増えてほしい。
    個人的には、大規模なWebプロジェクトより CLIツール のようなところで新しい言語を試しやすい

  • 2023年に投稿された Unisonレビュー記事 を参考にしたが、かなり役に立った

  • アイデアは興味深いが、Unisonは 言語 + ソース管理 + ホスティング を一度に導入しなければならない オールインワン構造 だ。
    スタックのどれか一つでも気に入らなければ、全体を使うのは難しい。
    だから、こうしたアイデアがそのまま広く普及するのは難しそうだ

    • Unisonは段階的に導入できる。
      言語自体の ツール品質 は非常に高く、既存システムとの統合も可能だ。
      例えばUnison Cloudは大部分がUnisonで書かれているが、一部にはHaskellも使っている。
      関連議論: HNスレッド1, HNスレッド2
      複数の技術を有機的に設計し、互いにうまく連携するようにすること自体に大きな価値があると思う
    • 商業的成功の有無よりも、このプロジェクトが示している 計算機科学的な研究価値 そのもののほうが、より興味深い評価軸だと思う