Mitchell HashimotoによるGhostty、Zig、そしてターミナルエミュレータの未来について

Ghostty: GPUプログラミングとターミナルエミュレーションの架け橋

Mitchell Hashimotoは、HashiCorp在籍中に鈍ってしまった技術領域、具体的にはGPUプログラミング、シングルノードのシステムプログラミング、そしてZig言語におけるスキルを研ぎ澄ますためにGhosttyを作成しました。15年間にわたりCLIアプリケーションを構築してきたHashimotoは、ターミナルエミュレータが実際にどのように機能しているかについての深い理解が不足していることに気づきました。

Ghosttyは、高速で機能豊富、かつネイティブにクロスプラットフォームであるターミナルを構築したいという願望から生まれました。当初は友人向けのプライベートなプロジェクトとして始まりましたが、肥大化（bloat）を導入することなく、カスタマイズ（riceable）可能で調整可能な公開ツールへと進化しました。Hashimotoは「肥大化」を、使用していない時にパフォーマンスをコストとして支払う機能と定義しています。彼は、検索のような機能を、ディスクやRAMは占有するものの、明示的にトリガーされない限りは休止状態を維持するように設計しています。

ターミナルプロトコルとAPIの再考

Hashimotoは、現在のターミナルエコシステムが、まとまりのあるビジョンに基づいているのではなく、レガシーな仕様や、人気のあるターミナルがたまたま行っていることに基づく「事実上の標準」の寄せ集めに依存していると主張しています。彼は、PTYのインバンド・シグナリング（エスケープシーケンスを含む非構造化バイトストリーム）を根本的な問題として特定しています。

ターミナルを進化させるために、Hashimotoは2つの具体的なアーキテクチャの転換を提案しています。

n-screen API

現在、ターミナルは通常、2つのモードのみをサポートしています：メインスクリーン（スクロールバックあり）と、代替スクリーン（NeovimのようなTUIで使用される）。Hashimotoは、個別のグリッドサイズを持つ無制限のバックグラウンドスクリーンを可能にする「n-screen API」を提案しています。これにより、ターミナルエミュレータは行の折り返しやマウスイベントを処理しつつ、各スクリーンをスタンドアロンのネイティブウィンドウとしてレンダリングすることが可能になります。

構造化ボタンプロトコル

既存のマウスプロトコルは、現在のスクリーン上のセルがクリックされた時のみターミナルに通知します。Hashimotoは、OSC 8（ハイパーリンク）に似たプロトコルを提案しており、プログラムがボタンを定義することで、コンテンツが履歴にスクロールした後でも機能し続けるボタンを実現しようとしています。これは、Claude Codeのような現代的な「メインスクリーン」アプリケーションにおいて、履歴の出力からファイルやリンクを開く能力が失われている現状において、特に有用です。

オープンソースとメンテナンスに関する哲学

Hashimotoは、オープンソースのメンテナーとユーザーの関係について厳格な姿勢を維持しており、ほとんどのライセンスの「現状渡し、保証なし」条項が主要な合意事項であると強調しています。

• 主体性とフォーク（Forking）: 彼は、特定のニッチなニーズにのみ応える機能や修正を要求するのではなく、プロジェクトをフォークすることをユーザーに推奨しています。彼は、フォークを躊躇することを「力を奪われるマインドセット」と見なし、もしユーザーが特定の保証や安定性を求めるのであれば、商業ソフトウェアを購入すべきだと主張しています。
• Holistic Design vs. 機能リクエスト: Hashimotoは、あらゆるPRをすべて受け入れることで生じる「コードの山」に対して警告を発しています。彼は、個々の症状をパッチで解決するのではなく、単一の、よく設計された機能が複数の個別の問題を同時に解決するような、ホリスティック（全体論的）なアプローチを提唱しています。
• AIの役割: AIが生成するコードの品質が「ゴミ」であることを認めつつも、Hashimotoは、方向性をテストするための迅速なプロトタイピング（「sloppifying demos」）にAIを使用しています。彼は、AIが将来的にZigのような言語における破壊的変更の苦痛を軽減し、状態Aから状態Bへの移行を自動化することで、その負担を減らすことができると考えています。

言語の選択: Zigと開発の「文化」

HashimotoはGhosttyのためにZigに多大な投資を行っており、コンパイルツールの充実や、APIを改善するために必要な破壊的変更を厭わないBDFL（Andrew Kelley）の姿勢を称賛しています。

しかし、彼の言語の選択は、技術的な側面だけでなく、文化的な側面も大きく関わっています。彼は、最小公約数を目指す言語よりも、独自のアイデンティティを維持する「容赦なく奇妙な」プロジェクトを強く好みます。コミュニティの議論で論争点となった点として、Hashimotoは、Rustの技術的な利点は尊重しつつも、「Rust文化」は好きではないと明示的に述べています。

"The philosophy behind the language and the language itself is really good. I just don’t want to use it... I really like the fact that certain languages lack certain features other languages enjoy, because these constraints breed creativity and culture."

技術的学習とAPI設計

今日のシステムプログラミングを学ぶ人々に対し、Hashimotoは、特定の言語（C, Zig, or Rust）よりも、基礎となるハードウェアを理解することの方が重要であると示唆しています。彼は、CPUスケジューリング、メモリキャッシュ階層、ファイルシステムを学習することを推奨しています。

彼のAPI設計のアプローチは、多様なエコシステムからの「概念の移植」に基づいています。異なる言語のライ組みちに（例：JavaのビルダーパターンをRubyで探索すること）を通じて、最も使い勝手の良いエルゴノミクス（人間工学的なパターン）を組み込むことを目図しています。彼はAPI設計における「名詞」の重要性を強調しており、Vagrantが成功した理由は、その設定やCLIがデプロイメント（展開）重視ではなく、開発に焦点を当てた名詞を中心に構成されていたからだと述べています。