本期热点#

Mitchell Hashimoto 在 HN 上很少缺话题度。这位 Vagrant、Terraform、Vault 等一系列基础设施工具的创建者，如今把精力倾注在终端模拟器 Ghostty 上。在一篇新访谈中，他罕见地系统性谈到了终端协议的未来、为什么选择 Zig 而不是 Rust，以及他对开源维护者与用户关系的独特立场。

本期讨论的几个话题恰好构成了一组有趣的对照：一边是对编程工具极致控制力的追求，另一边是美国救护车计费体系中被法律意外锁死的制度设计——两者都触及了"系统如何被设计"这一底层命题。

技术与产品#

专访 Mitchell Hashimoto：终端、Zig 与开源哲学#

Mitchell Hashimoto 在过去十五年里为开发者社区贡献了 Vagrant、Packer、Consul、Terraform、Vault、Nomad 等工具，其影响力横跨云基础设施和安全领域。在这次深度访谈中，他分享了自己从分布式系统转向桌面端和 GPU 编程的心路历程，以及 Ghostty 终端模拟器的诞生故事。

关于终端，Hashimoto 的观点非常清晰：终端应该是一个独特的应用平台，而不是浏览器的替代品。他反对把视频、麦克风、响应式布局等一切功能塞进终端，认为基于文本的、等宽网格的应用本身有其不可替代的价值——它们更容易实现、交互更简洁、安全模型更清晰，且在可组合性上远超图形界面。但他同时指出，终端协议需要根本性改进。他设想中的改进包括：支持无限数量的后台"屏幕"（可让 Neovim 的标签页变成原生窗口标签页）、以及一套按钮协议，使用户在滚动回历史记录时仍可点击交互——这对 Claude Code 等主流屏幕应用尤为关键。

关于 Zig 语言，Hashimoto 坦言，自己最初只是想在一段闲暇里玩玩 Zig 并写个能跑 vim 的终端然后丢掉。但他越深入了解终端生态，越发现没有一个终端同时满足快速、功能丰富和原生跨平台三个条件。Zig 社区对语言的"非妥协式"态度令 Hashimoto 欣赏，即便他不完全同意 Zig 的所有立场。在被问及 AI 对语言向后兼容性的影响时，他给出了一个务实的观察：当 Zig 0.15 的 writer 接口发生重大变更时，他借助 AI 自动完成了约 90% 的迁移工作。虽然他自嘲"不是 AI 鼓吹者"，但这一经验暗示了未来语言演进的一个可能方向——不兼容的升级成本可能不再那么可怕。

开源维护者与用户的关系是访谈中最直言不讳的部分。Hashimoto 反复强调一个常被遗忘的事实：开源许可证的第一行写的就是"按现状提供，无任何保证"。他认为，风投支持的开源项目塑造了一代人的预期——人们习惯了精美的网站、付费客服和 Discord 里的即时响应，却忘了开源的核心是自由和权利，而不是服务和保障。他的建议直白而有争议：“如果你想要更多控制权，就 fork 一个自己的版本。这不会比你要求我做的更多。”

HN 评论区的讨论主要集中在 Hashimoto 对 Rust 文化"不喜欢"的表态上。一场意料之内的 Rust vs Zig 论战迅速展开。有评论者指出，Hashimoto 只是在表达他支持"多元而非同质化"的社区文化观，并非评价 Rust 语言本身的好坏；一位长期 Rust 用户则从实际经历出发，描述了 Rust 社区中一些"技术上的正确但沟通上的居高临下"问题。支持 Hashimoto 的评论认为，不同编程语言社区本来就该有不同的气质——就像有人不喜欢足球一样自然——批评这种偏好的声音反而落入了 Hashimoto 所批评的"二元对错"陷阱。也有多位评论者提到，Ghostty 在实际使用中比 iTerm2 更流畅且 bug 更少，尽管功能面尚不如后者丰富。

讨论见 Hacker News 帖子

Lisp 入门指南：六十年前的编程语言为什么仍值得学习#

这篇面向初学者的 Lisp 导引文章试图回答一个老问题：当大多数现代语言已经吸收了 Lisp 的诸多理念之后，从头学习一门诞生于 1960 年代的编程语言，意义何在？

作者从三个层面展开论述。首先是宏系统——这里说的宏与 C、Rust 或 Swift 中的宏不是一回事。Lisp 的宏允许程序员在编译时像操作普通数据一样操作代码本身，这是由 Lisp 的同像性（homoiconicity，即代码和数据使用相同的列表结构表达）所保证的。这使得"程序可以写程序"不再是抽象概念，而是可以在 REPL 中实时观察到的日常实践。第二个特性是 REPL 驱动的交互式开发：Lisp 进程一旦启动就可以持续运行数周甚至数月，每次修改代码都是直接在活动进程中"进化"程序，无需停止-编译-重启。相比于今天许多技术栈仍在追求的"热重载"，Lisp 在上世纪 60 年代就已原生支持。第三个层面是软件的可扩展性。Emacs 和 AutoCAD 是 Lisp 扩展能力的经典案例——前者通过 Emacs Lisp 几乎可以被改造成任何类型的应用，后者通过 AutoLISP 让工程师能够自动化重复任务和创建复杂几何图形。

文章坦诚地承认：Lisp 所谓"属于它的时代"从未到来，也大概率永远不会到来。但它作为仅次于 Fortran 的历史第二悠久的仍在使用的编程语言，其影响力渗透在几乎所有现代语言的设计之中。

HN 社区的讨论跳出了"该不该学 Lisp"的框架，转向了更深层的问题。一条获赞很高的评论将编程语言分成了"光明面"（约束型：预防程序员犯错，如静态类型系统）和"黑暗面"（赋权型：给予程序员最大自由度，如宏和自修改代码），并指出 Lisp 的独特之处在于它兼具两者的某些特质——这使它"几乎不可腐化"。关于 Lisp 在企业中难以普及的讨论也颇为务实：多位评论者指出，约束较少的语言在团队协作中容易造成不同水平开发者之间的代码质量差异，这也是 Go 和 Rust 等相对"约束型"语言近年更获企业青睐的原因之一。

讨论见 Hacker News 帖子

社会与文化#

美国救护车为什么这么贵：一笔被制度锁死的账单#

这篇引起广泛讨论的文章从一个真实而令人窒息的故事讲起：一名旧金山的 25 岁年轻人被车撞伤后，坚持联系朋友开车送他去医院而不是叫救护车，因为他"知道救护车很贵"。后来他被迫接受了一次仅六英里的医院间转运，收到了 12,873 美元的账单。即使保险公司最终同意支付约一万美元，他仍需自掏约 2,900 美元。

作者 David Oks 用一个金融学上的"期权"比喻来解释问题的根源：救护车服务本质上是在出售"救援期权"——其核心成本不是出车本身，而是全天候守候的固定投入。但美国的支付结构自 1965 年 Medicare 立法以来一直按"每次出车收费"的模式运行，这导致成本与收入严重错配。具体来说，Medicare 和 Medicaid 支付的价格远低于成本（平均每趟成本约 2,673 美元，Medicare 仅支付约 329 美元），无保险患者大多无力支付，所有缺口最终被迫转嫁到少数有私人保险的患者身上——他们中的约一半会收到"意外账单"。这种逆向结构解释了为什么美国救护车行业实现了"收取惊人价格同时也在破产"的罕见组合，以及为什么"救护车荒漠"正在美国农村地区蔓延。

文章指出，大多数发达国家已通过不同方式解决了这个问题：英国和日本直接通过税收资助救护车；澳大利亚维多利亚州每年每户收取约 70 澳元的会员费即可无限次使用。美国部分地区也在尝试类似模式：塔尔萨和俄克拉荷马城允许居民每月在电费账单中预缴几美元，一旦需要救护车上门则无需再付费。

HN 评论区的讨论相当扎实。有读者认为文章用期权比喻解释固定成本问题"虽然是巧妙的修辞但并非必要"，问题的核心就是政府和保险公司支付不足。但这一观点立即遭到反驳：更有力的解读是，“支付不足"这一说法本身是"按次收费"思维的延续——如果承认救护车应该像消防部门一样由公共财政维持待命，那么压根不应该按单次出车来讨论"成本"和"支付”。来自英国、荷兰等国的用户分享了本国的费用对比：英国一次救护车出诊约 450 英镑，荷兰急诊约 877 欧元（且大部分由保险承担），这些数据凸显了美国系统的异常。此外，评论中也有人分享了正在推动本地公共 EMS 会员制的实践经验，包括车辆维护和人员工资的具体成本数据，为"这问题可以解决"提供了接地气的佐证。

讨论见 Hacker News 帖子

尾巴#

今天的几篇内容恰好从不同角度回响了同一个问题：好的系统设计究竟应该约束使用者，还是赋予使用者更大的自由度？Mitchell Hashimoto 选择了后者——无论是 Ghostty 对终端 API 的重新想象，还是他对开源自由的坚持；Lisp 用六十年的时间证明，放弃对程序员的约束可以释放出惊人的创造力；而美国救护车体系的故事则是一个反面教材——一项 1965 年草草写下的付款规则，阴错阳差地锁死了整个急救系统的经济逻辑，让普通人在最无助的时刻还要面对一场财务赌博。

好的系统让人感觉自由，坏的系统让人感觉无力。今天的讨论值得我们在设计下一套规则时多想一想。

我们下期再见。