ミッチェル・ハシモト インタビュー: Ghostty、Zig、オープンソース保守
(alexalejandre.com)- Mitchell HashimotoはVagrant、Terraform、Vaultの後、GhosttyとVouchを作りながら、ターミナル・Zig・オープンソース保守・製品品質に対する自分の基準を整理している
- Ghosttyは、GPUプログラミング、デスクトップ/単一ノードのシステムプログラミング、Zigを学ぶための個人プロジェクトとして始まり、高速で機能豊富なネイティブのクロスプラットフォーム端末を目指して発展した
- ターミナルはブラウザのようにあらゆる機能を抱え込むよりも、テキストベースアプリの構成可能性、自動化、明確なセキュリティモデルを活かすべきであり、PTYの非構造的なバイトストリームは依然として限界として残っている
- オープンソース保守者はユーザーに義務を負わないが、良いソフトウェアを作るには個別の要望をそのまま受け入れるより、複数の問題を1つの一貫した機能で解くべきだと考えている
- Zigの大きな変更はダウンストリームに負担を与えるが、APIとコンパイルツールの品質を高めており、AIは大規模変更の反復作業を減らして後方互換性の負担を下げられると評価している
Ghosttyが始まった理由
- Mitchell Hashimotoは、Vagrant、Packer、Consul、Terraform、Vault、Nomad、Waypointを作った後、現在はGhosttyとVouchを作っている
- Ghosttyは、約15年間CLIアプリケーションを作ってきたにもかかわらず、ターミナルエミュレータがどう動くのかをきちんと理解していなかったという問題意識から始まった
- Hashicorpを離れた後、再び取り組みたかった領域は3つあった
- AI以前の文脈におけるGPUプログラミング
- 分散システムとは異なるデスクトップ/単一ノードのシステムプログラミング
- Zigの利用
- 初期目標は、vimとコンパイラを動かし、Ghostty自身をビルドできるようにしたら捨てることだった
- ターミナルのエコシステムをさらに見ていくうちに、高速で機能豊富かつネイティブなクロスプラットフォームツールが不足していると判断した
- Discordの友人たちに共有した後、毎日使うユーザーが現れ、Ghostty Discordはもともとの友人グループチャットを専用スペースに変えたものだった
- 公開的な知名度が過度な注目を生むと考え、長い間非公開ベータとして運営していた
ターミナルはどこまで拡張されるべきか
- Hashimotoは、ターミナルを無理に巨大なアプリケーションプラットフォームへ押し広げる方向には反対している
- ターミナルはブラウザや過去のJavaランタイムのように、動画・マイクアクセス・レスポンシブレイアウトまで取り込むこともできるが、ブラウザ・デスクトップ・テキストベースの固定幅グリッドアプリはそれぞれ得意なことが違うと考えている
- テキストベースアプリケーションは素早く実装でき、相互作用しやすく、セキュリティモデルが明確であるべきだ
- ターミナルベースアプリの強みは構成可能性にある
- TUIはその性格がやや弱いが、ほとんどのCLIツールはstdin/stdoutを超えて関数のように使える仕組みを持っている
- UNIXの「1つのことをうまくやれ」という哲学がその極端な例だ
- NeovimやAIツールは、ますます多くのコマンドラインフラグを提供している
- より良いターミナルアプリケーションは、より良い自動化とスクリプト可能性につながる
- PTYのインバンド信号、つまりエスケープシーケンスを含む非構造的なバイトストリームは、大きな問題として残っている
- Nushellエコシステムは別レイヤーでこれを直そうとしているが、Hashimotoはより根本的な改善が必要だと考えている
- Microsoftエコシステムを嫌う人も多いが、PowerShellは構造化データの面で多くを正しくやっていると評価している
レガシーではないターミナルAPI構想
- 新しいターミナルAPIを考える際、Hashimotoはブラウザ、Emacs、Apple、Microsoft、Android、ゲームコンソールのような巨大アプリケーションプラットフォームのフレームワークを参考にしている
- WebのDOMとJS API、AppleのAppKit・Cocoa・SwiftUI、WindowsのWin32・WinUI、LinuxのGTK・Qtのように、すでに蓄積された先例をまず調べるべきだと考えている
- クリップボードアクセス1つを取っても、歴史的なターミナルプロトコルはテキスト中心だが、デスクトップは画像や複数のMIMEタイプをずっと前から扱ってきたため、各プラットフォームのクリップボード文書を見る必要がある
- まだGhosttyにカスタムプロトコルは導入していない
-
n-screen API
- 現在のターミナルには通常、main screenとalt screenの2種類がある
- main screenはシェルとスクロールバックに近く、alternate screenはNeovimやほとんどのTUIに近い
- この構造はどちらか一方のモードをオン/オフする方式で、通常は全画面を占有し、スクロールバックを失う
- Hashimotoは、バックグラウンドに無制限の画面を作って埋められるn-screen APIを構想している
- 画面ごとに異なるグリッドサイズを持たせてオーバーレイでき、ターミナルエミュレータが改行・選択・マウスイベントのルーティングを処理できる
- 特定の画面を独立ウィンドウとして指定すれば、ターミナルエミュレータがグリッド外にレンダリングすることもできる
- 例として、Neovimタブをネイティブウィンドウタブのように同時に開ける形を挙げている
-
ボタンプロトコル
- 現在のマウスプロトコルでは、ユーザーが現在の画面のグリッドセルをクリックしたときにしかイベントを受け取れない
- スクロールバックに入った履歴項目ではクリックイベントを受け取れない
- ターミナルは現在、ハイパーリンクプロトコルであるOSC 8をサポートしている
- HashimotoはOSC 8に似た形で、クリック時にプログラムへ指定メッセージを送るボタンプロトコルを構想している
- たとえば
open_profileIDを持つボタンは、ユーザーが履歴へスクロールしても登録状態のまま残せる - この機能はスクロールバックのあるmain screenアプリケーションに影響し、Claude Codeのようなmain screenアプリで、ファイルを開く操作やアプリ内リンクが履歴に入ると動作しなくなる問題につながっている
標準不在とオープンソース保守
- HashimotoはPTYプロトコル全体をWaylandに置き換える実験をしたが、やめた
- ターミナルはウィンドウやウィンドウウィジェットを管理するウィンドウイングサーバーのように見なせ、Waylandはローカルデスクトップとウィンドウレンダリングの問題を解く良いプロトコルだと考えている
- ターミナルの問題の1つは、もはや標準化機関が存在しないことだ
- 古い仕様は残っているが、この20年間の標準化は、最も人気のあるターミナルが何をするかを基準に進んできた
- 結果として多くの機能が混ざり合い、趣味性のあるビジョンを押し進める主体はいないと見ている
- 今後の道筋は決めておらず、ターミナルではない新しいテキストベースアプリケーション空間を作り、レガシーアプリ向けにターミナル翻訳レイヤーを載せる方向もあり得ると考えている
-
ユーザー要求と大きなビジョンのバランス
- Hashimotoは、オープンソース保守者のユーザーに対する義務はゼロだと公言してきた
- オープンソースライセンスの最初の一行は「as is, no warranty」であり、ユーザーは無料ソフトウェアを受け取る代わりに要求する権利を持たないという立場だ
- 同時に、良いソフトウェアを作りたいので、問題を直し、ソフトウェアをより良くする責任感は感じているという
- ある日はイシューを見て他人の問題を直し、ある日はイシュー・議論・PRを見ず、自分が望むことに集中する
- 毎日ユーザーイシューだけ処理していると安定していても停滞したソフトウェアになり、すべてのPRを受け入れると変化はしてもビジョンが失われると考えている
- ほとんどの貢献は特定の個人の問題をかゆいところだけ掻く程度であり、全部受け入れるとコードが山のように積み上がると述べている
- 逆に、問題を深く理解すれば、複数の機能要望を1つの優雅なシステムで同時に解決できる
- 機能設計動画では、3〜4個の個別機能要望を閉じ、それらと別の1つの機能で同時に解決した例を紹介している
-
機能の豊富さと肥大化の区別
- Ghosttyで最も多く要望された機能の1つだった検索は実装され、リリースされた
- 一部ユーザーは検索がGhosttyのミニマリズムを壊し肥大化だと批判したが、HashimotoはGhosttyを機能豊富なターミナルとして宣伝していると答えた
- 彼は機能の豊富さと肥大化を区別している
- 検索機能はディスク容量とRAMのロードは消費するが、使わなければ何のコードも実行されないよう設計されている
- したがって、使わないユーザーにとっては実行コストのない機能だと見ている
- Ghosttyは、ユーザーの必要に合わせて整えられ、デフォルトのままでも動作し、必要になるか検索するまでは機能を隠すターミナルを目指している
- 機能削除フラグを維持してほしいという要望については、保守者がそのフラグを管理することと、ユーザーが機能を削除したフォークを維持することは同種の要求だと考えている
オープンソースの権利、Zigの変化、API品質
- Hashimotoは、個人フォークと継続保守されるフォークがもっと増えるべきだと信じている
- ベンチャー投資ベースのオープンソースは、Webサイト、有償サポート担当、Slack・Discordサポートを備えた洗練されたプロジェクトを期待する世代を作ったと見ている
- しかし、オープンソースの核心は製品保証ではなく自由と権利だ
- 好きなように使う
- 修正する
- フォークする
- 安定性や保守義務はそうした権利には含まれない
- セキュリティ脆弱性を含むコミットが入ったとしても、それを保守者だけの責任にはできず、ユーザーがそのコミットをレビューしなかった責任もあると述べている
- より強い保証と、誰かを責める権利を望むなら、ソフトウェアに費用を払い、ベンダーと顧客の関係を結ぶべきだという立場だ
- 個人プロジェクトでは、自分が遭遇していないバグを直すPRであってもマージしないことがある
- マージは、そのコードを永遠に保守するという約束だからだ
-
Zigに対する姿勢
- HashimotoはZigを選ぶときに何を引き受けるか理解しており、コンパイラパッチを書きながらコミュニティ、文化、哲学を理解するようになった
- まだ始まっていないI/O変更は、Zigで最も難しい作業の1つになると予想している
- Zigの人気は高まっているが、Andrewは必要だと感じる変更から引き下がらず、Hashimotoはダウンストリームユーザーとしてその点を好意的に見ている
- Zig 0.15はwriterインターフェースを変え、出力するほぼすべてのコードに影響を与えたが、API自体ははるかに良くなったと評価している
- Zigはコンパイルツールに集中しており、コンパイル速度を上げるために言語機能を削ることもあった
- lib-ghosttyのターミナル全体を即座にビルドできるが、Andrewはそのミリ秒単位の時間すら遅すぎると考えているという
- Zig 1.0にはいつか到達するだろうが、まだ数年はかかると見ている
- AIは、言語変更によって生じるダウンストリームの痛みを減らせる
- さまざまな文脈で変更方法を示した後、残りを適用させると、大きなdiffの約90%が自動処理されたという
- Aの状態からBの状態へ行く方法を説明できるなら、後方互換性の意味が薄れる未来を示唆していると考えている
- Zigの強い反AI方針とは皮肉だが、AIは変更がダウンストリームユーザーに与える苦痛を和らげると見ている
-
ライブラリとAPI設計
- 良いライブラリ設計のための最も具体的な方法は、多くのコミュニティの多くのライブラリを実際に使ってみることだ
- 実務で使わないプログラミング言語を学ぶように、さまざまなエコシステムのライブラリを使うと視野が広がる
- 大学時代、Prolog、Haskell、Clojure、Javaでおもちゃのプロダクトを作りながら、各エコシステムのビルドシステム、使い勝手、ライブラリ、Webフレームワーク、Webサーバー、アプリサーバーを学んだ
- 各エコシステムの文化は、ライブラリやフレームワークの関心の分離やAPIの形に染み込むと考えている
- Javaで長く使われてきたbuilderパターンをRubyで試してみて良いと感じた経験を、概念移植の例として挙げている
- Dockerは、デプロイやランタイム面の多くの要素が開発フローに混ざると見ており、Vagrantは開発に直接焦点を当てた名詞、CLI、設定を意図的に使ったと述べている
-
ツール製作者のジレンマと技術スタック
- Hashimotoは、自分は生涯ツール製作者であり、ツール製作者のジレンマを信じていると語る
- ある問題を切実に理解して理想のツールを作るが、そのツールが人気になると、実際のユーザーではなく現場感覚を失ったツール製作者になってしまう問題が繰り返されうる
- ターミナル自体は毎日使っているが、TUI開発は十分にできておらず、多くのメール・IRCクライアントを保守し仕様も書いているrockoragerのような保守者に依存している
- 現在の技術スタックについては、「悪くない」という程度の態度だ
- フロントエンド、TypeScript、React型のコミュニティには良い点も多いが、変化が多すぎ、複雑性が高く、抽象化レイヤーが明確でないと見ている
- HTTP/1からHTTP/2、HTTP/3へ進む変化のように、多くの領域で複雑性は非線形に増加したと述べている
- 業界は速く動きすぎており、もっと単純でよかったものを複雑にしていて、AIと関連ツールがそれを加速していると見ている
原則、文化、品質、学習
- Hashicorpの原則文書もGhosttyの開発方式も、すべてHashimoto個人の反映だったため、毎日実践しやすかったという
- 自分と異なる原則を立てると、新年の抱負のように実際の行動へ移しにくいと考えている
- GhosttyはクロスプラットフォームのコアとネイティブGUIの両方を重視している
- コアはクロスプラットフォーム
- GUIはクロスプラットフォームに固執せず、プラットフォームごとのネイティブ方式を好む
- オープンソースプロジェクトとインターネットは、異なる部族の集合であるべきだと考えている
- プログラミング言語が誰もが欲しがる機能を備えた最小公倍数的な存在になるのを嫌い、制約が創造性と文化を生むと語っている
- Rustの言語と哲学は良いが、Rust文化は好きではないと述べており、それはRustコミュニティの人々が悪いという意味ではないと区別している
- Zigは技術、コミュニティ運営、資金調達、PR、ブログ記事、話し方に至るまで、明確で二極化した立場を持っており、Hashimotoはその奇妙さを尊重して継続的に資金支援し、使っているという
- 品質を保ちながら素早く出荷するには、特定の顧客問題ではなく、ユーザーがその問題に至った文脈と上流の問題まで理解する必要がある
- 企業規模でこれをどう解くかは分からないが、自分は自分の作るソフトウェアの大きなユーザーとして判断していると述べている
- AIはデモや方向性確認にはラフに使ってもよいが、リリースするコードは読んで理解したうえで品質を担保して出すべきだと考えている
- Cを学ぶうえでは、言語そのものよりもコンピュータがどう動くかを理解することのほうが重要だ
- CPUスケジューリング、メモリ、キャッシュ階層、ファイルシステム、ディスクとファイルアクセスを理解すべきだ
- C、Zig、Rustのようにsyscall層のすぐ上で作業すると、何が起きているか理解しやすい
- Python、JavaScript、Rubyのファイルを開くAPIは多くの詳細を抽象化している
- 標準ライブラリ関数も当然視せず、誰かが書いたコードなのだから、自分で読んでどう動くか掘り下げるべきだと助言している
4件のコメント
同じような時間に上がってきたのに、雰囲気があまりにも違っていて面白いですねｗｗｗ
BunのRustへの再実装についての私の考え
笑…
wwwwwwwwwwwwwwwwwwwwwwwww
Lobste.rs のコメント
素晴らしいインタビューで、いちばんよかった一文は「すべてに同意するわけではないが、堂々と変であることを本当に尊重している」だった。
こういう姿勢がもっと増えてほしい。
先例とターミナルの進化を語るなら、Arcan と cat9 も少なくとも言及すべきだと思う。
https://arcan-fe.com/2022/04/…
「PowerShell は構造化データの扱いがうまい」というくだりで、Jörg W Mittag のこの回答を思い出した。
型付きの引数を使えば、パースはすべて PowerShell が処理してくれる。
Neovim のタブがネイティブのウィンドウタブとして同時に開く様子を想像するのも本当にいい。
C、Zig、Rust のようにシステムコール層のすぐ上で作業すると、何が起きているのかを理解するうえで大いに役立つ。
マシンとプログラマの間にある抽象化を剥がして基盤層に触れる過程は面白く、問題の本質により近づかせてくれる。
標準ライブラリはたいてい移植性を目標にしているため、OS 機能の最小公分母を含むことになるが、プラットフォームを最大限に活用できるとき、プログラミングははるかに楽しくなる。
標準ライブラリの関数も誰かが書いたコードなのだから、当たり前と思わず読んでみようという姿勢には大いに敬意を抱く。
Ghostty のスポンサー制度についてももっと知りたい。非営利として法人化されているようだが、どれほど成功していて、自立可能なのか気になる。
Windows の PowerShell は、この定義によれば完全に内部型であるという利点があるが、.NET Framework の上に構築されていて、ほぼすべての Windows API にアクセスし相互運用できるため、実際には大きく制限されていない。
UNIX は設計上外部型であり、Nushell の構造化された答えは、私の理解では厳密に内部型なので拡張性が低い。
Oils は外部との構造化相互運用のために json または独自拡張の json8 に賭けているが、どちらも PowerShell と比べるとかなり制限されているように感じる。
みんなで stdout には msgpack のようなものだけを流すことに合意し、すべてのターミナルを msgpack ビューアにしたらどうだろう、と思う。libc にパイプのシリアライズ／デシリアライズを入れようという請願でもすべきかもしれない。
ターミナルの標準化団体が消えただけでなく、シェルの世界もプロダクション基準ではほとんど革新がなかった。
Bash はいまだに Kornshell にすでにあった機能を追加しているし、Unix シェルには誰も取り除き方を知らない落とし穴があまりに多く、POSIX はほとんど動かない。
Oils や Nushell が主要ディストリビューションに採用され、この領域の革新はよいことだと人々が気づく、という夢を今もまだ抱いている。
それでも kitty はターミナル分野で確実に風穴を開けたし、調整は不足していても、革新が起きる段階までは来たように思う。
Mitchell の落ち着いた肯定・否定の判断を大いに尊重するようになった。
優れたターミナルを作り、ターミナルインターフェースを好んでいるが、ターミナルがすべてをこなしたり、極端に押し進められたりすることには同意していない。
プログラミング言語とコミュニティを深く気にかけ、それぞれの言語が固有の姿を持つことを望んでいるが、言語は結局目的のための手段であり、その下にある理解のほうが重要だということも知っている。
Rust コミュニティを個人的に好まないことは認めつつ、違う感じ方をする人を貶めない。
インターネットを複数の部族の集合として見ながらも、部族主義や「唯一の真の部族」探しに陥らない、かなり禅的な姿勢が印象的だ。
もっと多くの個人用・メンテナンス用フォークがあるべきだという考えには共感するが、どう促せばよいのかはよく分からない。
権利意識のスペクトルの低い側では、有償サポート契約のような企業向け要素には関心がなく、好きなパッケージマネージャからそのままインストールできる利便性だけを求めているかもしれない。
brew installやapt installから、複製したリポジトリとビルドツールを扱う段階へ移る初期摩擦を、何とか下げる必要がある。より高速なコンパイラが助けになるかもしれない。
ただしセキュリティに敏感なソフトウェアでは、ユーザーがあまり多くの変更をしないほうが利益になる場合があり、その摩擦自体が機能であることもある。
n-screen とボタン仕様の中間にあたる何かが、現代の UI には必要だという点に強く同意する。
もしかすると意味レイヤーと呼べば十分かもしれない。
このレイヤーがあれば、エージェント型ツールやメイン画面ツール、アクセシビリティ、組み合わせ可能なウィジェットやコントロールのようなものが可能になる。
n-screen とボタンは結局、どれだけ多くの内容を表現するかという左右の境界のように見える。
理想的には、この意味レイヤーはマルチカーソル、文字単位の折り返しではなく単語単位の折り返し、オーバーレイ（z-index、セルブレンディングなど）ももたらすべきだ。