Mitchell Hashimoto on Ghostty, Zig, and the Future of Terminal Emulators

Ghostty: Bridging GPU Programming and Terminal Emulation

Mitchell Hashimoto 為了磨練他在 HashiCorp 任職期間變得生疏的技術領域，特別是針對 GPU programming、single-node systems programming 以及 Zig 語言，而開發了 Ghostty。在建立了 15 年的 CLI applications 之後，Hashimoto 意識到自己對於終端機模擬器（terminal emulators）的實際運作方式缺乏深入的理解。

Ghostty 的誕生源於想要打造一個快速、功能豐富且原生跨平台的終端機。雖然它最初是作為朋友間的私人專案，但後來演變成一個公開工具，旨在實現「可配置性」（riceable）且具備高度自定義能力，同時又不引入冗餘功能（bloat）。Hashimoto 將「bloat」定義為在未使用時會消耗效能的功能；他設計的功能（例如搜尋）在佔用磁碟和 RAM 的同時，除非被明確觸發，否則會保持休眠狀態。

Reimagining Terminal Protocols and APIs

Hashimoto 指出，目前的終端機生態系統依賴於一堆過時的規範與基於熱門終端機行為的「事實標準」（de facto standards），而非一個凝聚的願景。他認為 PTY 的 in-band signaling——一種帶有 escape sequences 的非結構化位元組流——是一個根本性的問題。

為了推動終端機的發展，Hashimoto 提出了兩個具體的架構轉變：

The n-screen API

目前，終端機通常只支援兩種模式：主螢幕（帶有 scrollback）與替代螢幕（alternate screen，用於 Neovim 等 TUI 應用程式）。Hashimoto 提議一種「n-screen API」，允許擁有無限數量的背景螢幕，且每個螢幕都有獨立的 grid sizes。這將使終端機模擬器能夠處理 line wrapping 與 mouse events，同時允許螢幕作為獨立的原生窗口來渲染。

A Structured Button Protocol

現有的滑鼠協議（mouse protocols）僅在當前螢幕的單個 cell 被點擊時通知終端機。Hashimoto 建議一種類似於 OSC 8 (hyperlinks) 的協議，允許程式定義按鈕，即使在內容捲動到歷史紀錄中後，這些按鈕仍能保持功能性。這對於現代的「主螢幕」應用程式（例如 Claude Code）特別有用，因為目前從歷史輸出中開啟檔案或連結的能力目前仍是缺失的。

Philosophy on Open Source and Maintenance

Hashimoto 對於開源維護者與使用者之間的關係持有一種嚴格的立場，強調大多數授權條款中的「按現狀提供，不提供保證」（as is, no warranty）條款是主要的協議。

• Agency and Forking: 他鼓勵使用者將專案進行 fork，而不是要求僅服務於特定小眾需求的技術或修復，他將不願進行 fork 的行為視為一種「剝奪自主權的心態」（disempowering mindset），並主張如果使用者想要特定的保證或穩定性，他們應該購買商業軟體。

• Holistic Design vs. Feature Requests: Hashimoto 警告不要接受所有的 PR，以免造成「程式碼山脈」（mountain of code）的程式碼堆積。他主張一種整體性的設計方法，即透過一個設計良好的單一功能來同時解決多個個別問題，而非僅僅是修補症狀。

• The Role of AI: 雖然承認 AI 生成的程式碼品質可能很「垃圾」（trash），但 Hashimoto 使用 AI 進行快速原型開發（「sloppifying demos」）以測試方向。他相信 AI 最終會透過自動化從狀態 A 到狀態 B 的遷移，來減少 Zig 等語言中 breaking changes 的痛苦。

Language Choice: Zig and the "Culture" of Development

Hashimoto 為 Ghostty 投入了大量精力於 Zig，並讚賞其對編譯工具鏈的關注，以及 BDFL (Andrew Kelley) 願意為了改進 API 而進行必要的 breaking changes。

然而，他對語言的選擇不僅僅是關於技術，也關乎文化。他表達了對「毫不避諱地古怪」（unapologetically weird）專案的強烈偏好，而非那些力求成為「最小公分母」的語言。在社群討論中提到的一個爭議點中，Hashimoto 明確表示他不喜歡「Rust culture」，儘管他尊重該語言的技術優點。

"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."

Technical Learning and API Design

對於現今學習系統程式設計（systems programming）的人來說，Hashimoto 建議，特定的語言（C, Zig, 或 Rust）並不比理解底層硬體重要。他建議研究 CPU scheduling、memory cache hierarchies 與檔案系統。

他的 API 設計方法是基於從不同生態系統中「移植概念」（porting concepts）。透過使用不同語言的開發庫（例如，在 Ruby 中探索 Java 的 builder pattern），他旨在將最符合人體工學的模式整合到自己的工作中。他強調 API 設計中「名詞」（nouns）的重要性，並指出 Vagrant 成功的原因是因為其配置與 CLI 圍繞著以開發為中心的名詞，而非以部署為中心的名詞。