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

Ghostty: Bridging GPU Programming and Terminal Emulation

Mitchell Hashimoto 创建 Ghostty 是为了磨炼他在 HashiCorp 任职期间逐渐生疏的技术领域，特别是针对 GPU 编程、单节点系统编程以及 Zig 语言。在构建 CLI 应用 15 年后，Hashimoto 意识到自己对终端模拟器究竟是如何运作的缺乏深入理解。

Ghostty 的诞生源于构建一个快速、功能丰富且原生跨平台的终端的愿望。虽然它最初是一个为朋友们准备的私人项目，但它随后演变成了一个旨在实现“可配置性”（riceable）且在不引入臃肿功能的情况下实现高度定制化的公共工具。Hashimoto 将“臃肿”定义为那些在不使用时会消耗性能的功能；他设计的搜索等功能在占用磁盘和 RAM 的同时，除非被显式触发，否则会保持休眠状态。

Reimagining Terminal Protocols and APIs

Hashimoto 认为当前的终端生态系统依赖于各种过时的规范和基于热门终端“实际上是怎么做的”的“事实标准”，而非一个凝聚的愿景。他指出 PTY 的带内信号（in-band signaling）——即带有转义序列的非结构化字节流——是一个根本性问题。

为了推动终端的发展，Hashimoto 提出了两个具体的架构转变：

The n-screen API

目前，终端通常只支持两种模式：主屏幕（带有回滚功能）和备用屏幕（由 Neovim 等 TUI 应用使用）。Hashimoto 提出了一种“n-screen API”，允许拥有无限数量的、具有独立网格大小的后台屏幕。这将使终端模拟器能够处理换行和鼠标事件，同时允许屏幕作为独立的原生窗口进行渲染。

A Structured Button Protocol

现有的鼠标协议仅在点击当前屏幕上的单元格时通知终端。Hashimoto 建议使用一种类似于 OSC 8（超链接）的协议，允许程序定义按钮，即使在内容滚动到历史记录中后，这些按钮仍然有效。这对于现代“主屏幕”应用（如 Claude Code）特别有用，因为目前从历史输出中打开文件或链接的能力已经丢失了。

Philosophy on Open Source and Maintenance

Hashimoto 对开源维护者与用户之间的关系持有一种严格的立场，强调大多数许可证中的“按现状提供，不提供任何保证”条款是主要的协议。

• Agency and Forking: 他鼓励用户进行 fork，而不是请求仅服务于特定小众群体的功能或修复。他认为拒绝 fork 是一种“剥夺自主权的心态”，并认为如果用户想要特定的保证或稳定性，他们应该购买商业软件。
• Holistic Design vs. Feature Requests: Hashimoto 警告不要接受每一个 PR 而导致产生“代码山”。他主张一种整体性的设计方法，即通过一个设计良好的单一功能来同时解决多个独立问题，而不是仅仅修补症状。
• The Role of AI: 虽然承认 AI 生成的代码质量堪称“垃圾”，但 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 而愿意做出必要的破坏性变更。

然而，他的语言选择更多是关于文化而非技术。他表达了对“毫不掩饰地古怪”且保持独特身份的项目，而非那些力求成为“最大公约数”的语言的强烈偏好。在社区讨论中一个引起争议的点，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

对于当今学习系统编程的人来说，Hashimoto 建议，具体的语言（C, Zig, 或 Rust）并不比理解底层硬件重要。他建议研究 CPU 调度、内存缓存层级结构和文件系统。

他的 API 设计方法基于从不同生态系统中“移植概念”。通过使用不同语言的库（例如，在 Ruby 中探索 Java 的 builder pattern），他旨在将最令人愉悦的工程化模式引入到自己的工作中。他强调了 API 设计中“名词”的重要性，指出 Vagrant 成功的原因在于其配置和 CLI 围绕着以开发为中心的名词，而非以部署为中心的名词。