Lobsters 专访 mitchellh

# Mitchell Hashimoto 访谈 来源：https://alexalejandre.com/programming/interview-with-mitchell-hashimoto/ 与 Mitchell Hashimoto 对话2026年7月 \- Alex Alejandre --- Mitchell Hashimoto (https://mitchellh.com/) 是Vagrant (https://vagrantup.com/)、Packer (https://packer.io/)、Consul (https://consul.io/)、Terraform (https://terraform.io/)、Vault (https://vaultproject.io/)、Nomad (https://nomadproject.io/)、Waypoint (https://waypointproject.io/) 的幕后推手，如今正在构建Ghostty (https://ghostty.org/) 和Vouch (https://github.com/mitchellh/vouch)\. 在这次访谈中，我们聊了终端、Zig 和开源。 --- **你接受过*很多*次访谈。为什么人们喜欢采访你？** 每次访谈，大家的角度都不同。很多人想知道从软件工程师到创业者的思维转变是如何发生的。也有些人关注产品层面，我在 Hashicorp 做过的工作，或者现在的 Ghostty。而这次的不同之处在于，我们没有预设的议程——你我都没什么要推销的。 **你觉得终端有什么好玩的？比如，为什么做 Ghostty？** 我花了大概 15 年时间构建 CLI 应用程序（不是现在常见的 TUI）。在这个过程中，我无意中学会了如何给文字上色、移动光标等。离开 Hashicorp 后，我想打磨自己的技术能力（因为疏于维护已经变得生疏了），具体想钻研三个方面：AI 之前的 GPU 编程、桌面/单节点系统编程（之前大量时间花在分布式系统上，网络开销占主导，你根本不用担心缓存局部性或向量操作）。另外，我非常想玩玩 Zig。我想同时满足这三件事。 做了 15 年 CLI 之后，我并不真正理解终端模拟器的工作原理。我知道终端的各个组件，但非常想弄懂它到底是怎么运行的，这样我就能同时涉足 GPU、桌面和 Zig。我的目标是让终端里能跑 vim 和编译器，然后让它自己构建自己，最后扔掉。但随着我对终端生态了解加深，我发现没有任何东西能满足我想要的：快速、功能丰富、原生跨平台。我把这个想法分享给了 Discord 上的几个朋友，他们问能不能再分享给别人，因为他们自己每天真的在用。Ghostty 的 Discord 原来只是我朋友的群聊，后来就改造成了这个项目。我不想公开发布，因为我的公众身份会招来太多不必要的关注，所以很长一段时间里我都只做了私人测试。 **我们如何进一步推动终端的发展？** 我不赞成把终端推向极端。当然，它是一个应用平台，能够做到其他基于操作系统的应用平台（比如浏览器、老的 Java 应用运行时环境）能做到的事情。你可以把全部功能都塞进去：视频和麦克风访问、响应式布局……你确实可以。 但浏览器有它擅长的，桌面有它擅长的，文本型（等宽网格）应用也有自己独特的优势。这些基于文本的应用应该能快速实现、易于交互、安全模型清晰。这个生态系统还有很多机会，我很想构建更多协议来支持它。 比起其他范式，终端应用更擅长组合。TUI 在这方面稍弱，但大多数 CLI 工具都有一些机制（超出标准输入输出）来像函数一样使用它们（UNIX 的“只做一件事”哲学是极致体现）。Neovim 和 AI 工具提供的命令行标志越来越多。更好的终端应用世界，就是一个更好自动化、更好脚本化的世界。 我想让终端成为一个特殊的应用场所。PTY 的带内信令（带有转义序列的非结构化字节流）是个大问题。Nushell 生态系统试图用另一层来解决它，但我们需要的是一项根本性的改进。很多人不喜欢微软的生态系统，但 PowerShell 在结构化数据方面做对了很多事情。 **你对非传统终端 API 有什么看法？** 我的指导方针是：我们现在有了多个主要的大型应用平台：浏览器、Emacs、整个苹果生态、微软生态、Android、视频游戏主机平台。这些生态系统各有优劣，但它们的框架是如何工作的？Web 上是 DOM 和 JS API；苹果上是 AppKit、Cocoa (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/WhatIsCocoa.html) 和 SwiftUI；Windows 上是 Win32、WinUI 等；Linux 上是 GTK 和 Qt 等。当有人说我们需要一种更好的方式访问剪贴板数据时（历史协议只支持纯文本，那图片、多种 MIME 类型呢？桌面端处理这些已经几十年了），我会去查每个平台的剪贴板管理器文档，看看它们最终采用了什么方案。我们没有理由在不去研究数十年已有成果的情况下，仅凭自己的理解去构建新东西。这就是我在尝试采取的方法。到目前为止我还没有引入任何自定义协议。 有两个协议特别让我想吐槽。目前，终端有一个主屏幕和一个替代屏幕（有时称为主屏幕和次级屏幕），属性不同。主屏幕像你的 shell，有回滚功能等等；替代屏幕像 Neovim、大多数 TUI 等。只有这两种模式：你打开或关闭一个模式，就会进入主屏幕或次级屏幕（占满整个屏幕、丢失回滚等）。 我想引入一个 n 屏幕 API，让你可以在后台创建和填充无限数量的屏幕，允许你以不同的网格大小叠加屏幕。终端模拟器可以处理换行、选择、鼠标事件路由等。你可以指定一个屏幕作为独立窗口，由终端模拟器在网格之外渲染——想象一下，你的 Neovim 标签页变成了本地窗口标签页，同时打开！这个基础层会解决很多问题。 另外，我还制定了一个按钮协议。目前有鼠标协议可以在用户点击网格单元格时收到通知。但接收事件的只能是当前屏幕上的内容，而不是历史记录，也不是滚动回退之后……现在我们支持超链接（OSC 8 (https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda)），我想要一个类似 OSC 8 的机制：点击时会发送一条消息（由你指定）给程序。你可以创建一个带有`open_profile`ID 的按钮，即使之后用户回滚历史，点击依然有效。这会影响主屏幕应用程序（只有它们有回滚功能），比如 Claude Code。我无意在这里讨论 AI，它只是一个非常流行的主屏幕应用程序。一旦内容进入历史记录，你就无法再打开文件、应用内链接等。 **这在多大程度上只是重做整个用户空间？这里面有相当大的范围蔓延风险。** 我曾经尝试用 Wayland 完全取代 PTY 协议。如果你眯着眼看，终端就像一个窗口服务器，管理窗口和窗口上的小部件。我研究 Wayland 是为了让 Ghostty 在它上面运行得更好，而且我觉得 Wayland 对于它试图解决的问题（本地桌面、渲染窗口）来说是一个相当不错的协议。但我后来放弃了。 终端的一个问题是，现在*已经没有*标准制定机构了。有一些旧的规范，是法律上标准化的，但过去 20 年的标准化是基于最流行的终端在做什么。我们有的是一堆杂七杂八的功能，没有哪个实体在推动一个有品位的愿景。 我不知道正确的道路是什么。你可以为基于文本的应用创建一个替代主场，不再叫终端，构建一些新的东西（上面加一个终端翻译层来兼容旧应用），尝试做一些不同的事情。 **你如何在这些想法和用户日常需求之间取得平衡？** 我非常公开地表示，开源维护者对用户没有0义务。开源许可证的第一行通常是“按原样提供，无任何担保”。这就是协议：你获得免费软件，不能对它提出要求。但我喜欢努力构建好的软件（可能有人不同意，说我的软件很烂），所以我确实有责任修复问题，让软件变得更好。 有些早晨我醒来，会期望去处理 issue，只解决别人的问题。但有时我醒来，专注于自己想要做的，不读一个 issue、讨论或 PR。有时候，你需要推动更大的愿景；有时候，你需要处理现实中的问题。 你可以在天空中建造一座完美的城市，然后回到现实世界，发现那里充满了恐怖和苦难。所以有时你需要清理一下。 如果我每天只处理用户的 issue，你会得到稳定但停滞不前的软件。如果你接受所有 PR，你会发生变化，但缺乏愿景。我不是要冒犯贡献者，但每几年只有一个人能从根本上理解。大多数贡献只是解决某个人的特定痒点，全部接受会导致代码堆积如山。真正理解了，有时你能发现优雅的系统，能简洁地解决一切问题。 我曾经做过一个功能设计视频 (https://x.com/mitchellh/status/2001810354096214059?lang=en)，在那里面我关闭了3-4个不同的功能请求，它们各自解决不同的问题，因为我发现一个单一功能（不同于所有这些）可以同时解决它们。很少有人能做到这一点，不是因为它难，而是因为它需要一种很少有人愿意花在别人项目上的关心程度。 > 我断断续续想了这个问题大概一年（同时还有上百件事，没有专门，我不在电脑前时总是在想这些东西）。当我终于坐下来想“我要解决这个问题”时，也许……1小时？https://x.com/mitchellh/status/2003957851514126510 **更少的功能，更好的组合，会吸引人们走向异域编程范式。这要求很高的视野。** 我最近在网上跟一个人因为我的理念发生过争吵。Ghostty 最被要求的功能之一是搜索，已经完成并发布了。但有人抱怨搜索臃肿，破坏了 Ghostty 的极简主义。我宣传 Ghostty 是功能丰富的！但我会区分这和臃肿。我不认为你应该为你没用的功能付出代价（除了磁盘空间或驻留内存代码外）。我解释了搜索的架构方式：它会占用磁盘空间并被加载到 RAM 中，但不会执行任何东西；如果你不用它，它就是一个免费功能。我希望 Ghostty 是一个可定制、可打磨的终端，能满足人们的需求，但也开箱即用，并在你需要或搜索到它们之前隐藏起来，而不会增加任何成本。 但如果你真的想要那样，那么 fork 并自己维护吧。这并没有要求你做比我要求你做的更多的事。如果你希望我维护一个标志来移除它，我可以要求你维护一个移除了它的 fork。告诉别人“去 fork”常常会惹恼他们。 **很少有人维护自己的补丁等，却要求整个项目迁就他们。这是一种非常丧失自主权的心态，乞求别人做自己很容易做到的事。** 我一直认为应该有更多的 fork，无论是个人 fork 还是维护的 fork。 我确实要归咎于自己，以及一般的风投支持的开源。有整整一代人期望看到高度打磨、有资金支持、有自身观点的项目，拥有网站和付费支持人员（在 Discord、Slack 等上），认为一个开源项目就是一个产品——而且在风投支持的案例中，它确实曾经是一个产品。但这在整个生态系统中是如此微小的一部分。 开源包括分享，但它本质是关于自由和权利。这是开源的核心，定义了 OSI 批准的开源许可证。你可以随意使用、修改和 fork 软件。这些权利中没有任何一条关于稳定性或维护义务。人们责怪维护者发布了安全漏洞，但为什么*你没有*审查那个提交呢？你和维护者有同样的义务去审查提交。但人们让维护者承担这种更高的责任，而他们本可以 fork 并立刻成为维护者。 如果你想要更好的保证，如果你想要有权利责怪别人，那就花钱买软件。当你和供应商之间有客户关系时，你就有权要求一些东西。但在开源中没有任何 entitlements。以你喜欢的方式使用它，这是得到你想要的东西的途径。如果更多人 fork，他们也会对构建者更有同理心。 有时候人们认为我的某个项目是一家公司，或者发送一个 PR 修复了我个人没有遇到的 bug，而我没有合并，因为合并意味着要永远维护它。在个人项目中，我不会合并，因为我没遇到那个 bug。 **消费别人不是产品的东西，你对 Zig 的发展有什么看法？显然你并不介意它还没有 1.0。** 我知道我参与的是什么。我通过编译器补丁进入了 Zig，并且很好地了解了社区。我对其文化、哲学等有很好的理解，所以我不会对任何事情感到不满。 我预计 I/O 的变更会是我们做过的最难的事情之一，但我们还没有开始。 Zig 越来越受欢迎，而 BDFL Andrew 并没有退让，坚持他认为必要的变更，作为下游消费者我挺喜欢这样。0.15 版本相当重要，改变了 writer 接口，因此所有打印内容的东西都受到了影响。但这个 API 确实好了太多。 Zig 正变得越来越好。他们非常注重编译工具，甚至移除了语言特性来提高编译速度，真是令人惊叹。你可以立即构建 lib-ghostty（整个终端），而 Andrew 还觉得这几毫秒太慢了。 我确实认为 Zig 最终会达到 1.0，尽管我觉得还有几年。当 AI 参与时，这就不那么重要了。我希望人们读到这篇文章时知道，我不是 AI 的狂热吹捧者。 在最基本的层面上，我们知道这些神经网络非常擅长模式匹配和模式填充。对于这类语言变更，我展示了如何在多种上下文中做，然后让它画完剩下的猫头鹰。虽然 diff 很大，但 90% 是自动完成的，而我在厨房里。这暗示着一个未来：如果你能解释如何从状态 A 到状态 B，向后兼容的意义就会小很多。 这有点讽刺，因为 Zig 有严格的反 AI 政策，但 AI 减轻了变更给下游用户带来的痛苦。 **你如何设计库和 API？Ghostty 使用了 lib-ghostty。我有个朋友对你库的易用性赞不绝口。除了“用心”之外，你有没有具体的方法来改进它们？** 最具体的方法是在多个社区中使用大量的库。就像学习一门你不会（专业）使用的编程语言一样，跨生态系统使用库会开阔你的视野并让你受益。大学期间，我花了很多时间涉猎冷门语言。我用 Prolog、Haskell、Clojure 甚至 Java 做了很多玩具项目（我从没做过专业的 Java 程序员，所以对我来说很新鲜。我用它写了一个完整的 web 副项目。我不喜欢它，但学到了很多关于构建系统、人体工程学、库、web 框架、web 服务器、应用服务器以及所有这类东西的知识。）每个生态系统都有不同的文化。这种文化当然是人的因素，但它会渗透到他们如何分离库和框架层面的关注点，如何设计那些 API 的外观。很长一段时间，Java 到处都在使用构建者模式，我在其他语言中没见过，但我在 Ruby 中尝试了一下，感觉相当不错。这是一个移植概念的例子。这就是我处理库设计的方式：尝试使用各种生态系统的库。