“宁愿放弃80%的工作机会,也不用AI写代码”!Android大神Jake Wharton谈Kotlin黄金时代、裁员与Google往事

在 Android 开发者社区，Jake Wharton 是一个很难绕开的人物。

他曾被开发者称为“Android 之神”，长期活跃于 Android 和开源社区，Retrofit、OkHttp、Picasso 等一批广为人知的开源项目背后，都有他的身影。

后来，他还加入 Google，参与推动 Kotlin 在 Android 上的落地。2017 年，Google 正式宣布将 Kotlin 作为 Android 的一等开发语言，而 Jake Wharton 也成为了 Google Kotlin 团队第一位工程师。

2020 年，他又回到 Square，随后在 Cash App 团队工作。2025 年 11 月，他在科技行业大规模裁员潮中离职。

离职之后，他公布了一份对下一份工作的 9 条要求，第一条就是：不加入 AI 公司、不做以 AI 为核心的产品，也不接受公司强制使用 AI。

这个选择的代价并不小。Jake Wharton 本人估计，这一条要求直接让他放弃了约 80% 的潜在工作机会。可即便如此，他依然把“不用 AI”放在第一位。

在 AI 编程工具已经成为行业主流的今天，一位参与过 Android、Kotlin 生态建设的资深工程师，为什么宁愿主动缩小自己的就业选择，也不愿接受 AI？Google 当初为什么选择 Kotlin？Kotlin 和 Swift 相比究竟各有什么优势？当 AI 正在改变程序员写代码的方式，Kotlin 的“黄金时代”是否已经过去？

在最近一次采访中，Jake Wharton 从自己的经历出发，谈到了代码、开发工具，以及 AI 时代程序员这个职业正在发生的变化。

Kotlin 是怎么成 Android 的一级编程语言？

主持人：2010 年，Java 是世界上排名第一的编程语言。Android 也是在 Java 上运行的。JetBrains 开发 Kotlin 是为了和它竞争吗？为什么要去做这种尝试？

Jake Wharton：Kotlin 出现的时候，正是 Java 语言有些停滞不前的时期。当时 Oracle 正在接管这门语言，发布周期依然长达两年，而 Google 的团队只能依赖 Java 语言所能提供的有限功能。

这就给其他人介入的机会。当时，社区正在寻找替代语言。有人使用 Scala，也有人尝试 Groovy，Kotlin 就是在大家渴望更现代的语言时应运而生的。随着 Java 生态系统之外的其他语言不断演进，你看到了很多令人向往的特性。

作为一家工具公司，JetBrains 能够将一门新语言与 IDE 以及周围的所有基础设施一起交付，这比一个完全从零开始的项目更容易被接受。此外，能够利用现有的生态系统，意味着你不需要抛弃现有的 Java 库或整个 Java 代码库。你可以逐步引入它，增量式迁移，并继续使用你已经熟悉的库。

主持人：2017 年，Google 宣布 Kotlin 成为 Android 的官方语言之一。你成为了 Google Kotlin 团队的第一位工程师。这是怎么发生的？

Jake Wharton：当时我在 Square 工作了五六年，而我们大约在三年前就已经采用了 Kotlin。我曾写过一份内部文档，论证为什么我们公司应该采用 Kotlin，以争取获得批准。我把那份文档公开了（https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit），因为里面没有任何针对我们专有场景的具体内容，它只是对这门语言的一个通用论证。

那份文档在 Android 社区引发了极大的关注。我成了一个深度参与这门语言演进并积极推广其使用的人。随着兴趣的增长，Google 的工程师们也认识到了 Kotlin 的潜在价值。我在那里认识的人开始向我暗示，官方支持很可能即将成真，并问我是否有兴趣参与其中。

我想象不到有什么比去那家为整个 Android 提供工具的公司，并把这门语言变成官方第一方产品，更能体现引入 Kotlin 这个想法的价值了。这是一个不容错过的机会。

主持人：Android 团队对采用 Kotlin 有什么阻力吗？

Jake Wharton：Android 团队起初肯定是有疑虑的。毕竟他们要从构建了 10 到 12 年、有着深度全栈集成且极为熟悉的技术，转向采用一种相对未经证实的技术，这种犹豫是必然的。

Kotlin 在当时也不过稳定了一两年，因此这些风险和担忧确实存在。Google 并不是完全不愿意承担风险，而是希望把风险控制在可接受的范围内，所以对 Kotlin 的引入采取了非常谨慎的方式。

这种采用并不是一夜之间完成的，而是一个渐进的过程。最开始，我们并没有急着用 Kotlin 重写已有的 Java 库，而是先为 Kotlin 开发对应的兄弟库。

这也恰恰体现了 Kotlin 的吸引力：它既有自己的语言特性，又很好地延续了 Java 的生态和开发习惯。开发者可以逐步把 Kotlin 引入现有代码库，而不需要为了拥抱这门新语言，在一夜之间把所有代码全部重写。

主持人：除了 Android 之外，Kotlin 还在哪里使用？

Jake Wharton：Kotlin 刚开始发展的几年里，Android 社区对它的支持非常强烈，也因此让不少人产生了一个误解：Kotlin 就是一门专门为 Android 打造的语言。甚至还有文章声称，Kotlin 是 Google 专门为 Android 开发的，这显然并不准确。

好在这种印象后来逐渐被打破。Kotlin 的应用范围已经从 Android 扩展到了后端服务，覆盖了过去主要使用 Java 的场景。以 Spring 为例，如今已经在整个产品体系中正式提供 Kotlin 的优先支持。

与此同时，JetBrains 也在持续推进 Kotlin Multiplatform（KMP）。Kotlin 开始被用于 iOS 应用，也出现在越来越多的桌面软件中。JetBrains 自己的 Toolbox 就是一个很典型的例子，它本身就是开发者获取和管理 JetBrains IDE 的工具。

不过，Android 早期的大规模应用并不意味着 Kotlin 只能用于 Android。恰恰相反，Android 反而成了 Kotlin 进入其他开发领域的一个重要跳板。

以 Square 为例，当时公司的后端服务几乎全部使用 Java。Kotlin 最初获准在公司内部使用时，也被限定在 Android 开发场景中。但后端团队看到 Android 团队使用 Kotlin 后越来越积极，也开始产生兴趣。最终，他们也获得了在后端项目中使用 Kotlin 的许可。

所以从某种意义上说，Android 并没有把 Kotlin 限定在移动端，反而成为了它走向更广泛开发场景的催化剂。

主持人：目前在生产环境中使用 Kotlin 的最大公司有哪些？

Jake Wharton：Meta、Google 和 Amazon。他们首先在移动端采用了它，但现在已积极应用于他们构建的后端服务和开发者工具中。比如，Meta 最近向 Kotlin 基金会贡献了他们的 Kotlin 格式化工具，使其成为官方的第一方格式化程序。

这些代表了世界上最大的一些代码库。能够将这种规模的系统迁移到 Kotlin，证明了这门语言的实力，也证明了他们对这门语言正在进行的长期投资。

为什么离开 Google？

主持人：Google 是许多工程师的梦想工作，也是 Kotlin 最大的采用者之一。然而你却在两年零九个月后离开了。为什么？

Jake Wharton：在去 Google 之前，我曾在 Cash App 工作。那时，我们已经成功采用了 Kotlin，并用它开发了几个开源库。后来，Google 决定在 Android 上正式支持 Kotlin。对我来说，加入 Google 并参与、推动这项工作，是一个无法拒绝的机会。

不过，刚加入 Google 时，我原本预计自己只会在那里待两年左右。我的目标很明确：帮助 Kotlin 成为 Android 上的一等语言，这样以后我自己也可以放心地使用它。

虽然我很享受构建工具和库，但并不想一直专注于基础设施工作。我更希望把自己创造的这些工具真正用起来，去开发面向用户的产品。

两年期限到了之后，我已经准备好转向产品工程。就在我准备提出离职时，管理层又批准了一个我非常想做的项目。为了把这个项目完成，我又多留了九个月。

最终，我还是决定回到产品开发中。对我来说，这也是享受自己参与打造的工具和语言所带来成果的一种方式。Google 确实有很多优势，但既然我已经完成了当初给自己设定的目标，那么也是时候继续往前走了。

主持人：你提到过你不喜欢 Google 的一些方面。这是什么意思？

Jake Wharton：它是一个极其庞大的组织。Android 团队本身非常棒，相对独立于 Google 的消费者产品生态系统，团队里全是我非常怀念共事的优秀同事。

我真正担心的是 Google 作为一家商业公司的属性。具体来说，Google 的商业模式很大程度上依赖于自己的专有生态和服务，通过这些产品和服务把用户留在自己的体系之内。

主持人：在 Cash App 工作了五年后，在 2025 年 11 月全行业裁员和科技动荡之际，你离开了。找新工作有多难？

Jake Wharton：并不是毫不费力。工作机会仍然存在，但我对自己想去哪里有具体的标准。因为我是根据自己的意愿主动离职的，所以我并没有陷入绝望或极其紧迫的境地。

机会就在那里，但市场与五年前需求泡沫、Android 工程师薪资被抬高的时期显然不同了。现在需要有针对性的努力，我非常同情那些面临非自愿工作变动的工程师。市场并没有完全崩溃，它只是需要更多的时间、耐心以及清晰的差异化定位。

主持人：目前在美国，一名高级 Kotlin 工程师的现实薪资范围是多少？

Jake Wharton：通常来说，基本工资的起薪在 20 万美元左右，之后会随着职位和经验逐步上涨，同时还会配有股权激励。按照标准的四年归属期计算，股权部分通常每年大约价值 10 万美元。当然，也有一些职位的薪酬会低于这个水平。

不过，现在各家公司在薪酬上都变得更加谨慎了，不再像过去那样愿意开出特别高的薪酬包。如果想拿到明显更高的收入，通常就得进入一些高风险、高回报的领域。

目前，生成式 AI 无疑是市场上最热门的方向之一，这类岗位的现金和股权薪酬往往会高得多。但与此同时，股权也意味着更大的风险：它可能最终一文不值，也可能带来数倍甚至十倍的回报。

归根结底，怎么选择还是取决于个人的风险承受能力和所处的人生阶段。就我现在而言，我更看重稳定、可预期的现金收入，而不是押注波动较大的股权。职业生涯早期，我其实很愿意承担这样的风险；但随着生活状况发生变化，我对工作的优先级也会随之改变。

主持人：在 2026 年，Kotlin 仍然是软件工程师的职业优势吗？

Jake Wharton：我现在已经不太确定，Kotlin 是否还能算得上一个明显的竞争优势。听起来似乎有些矛盾，但这恰恰说明了这门语言有多成功：它已经从一项能够让你脱颖而出的技能，变成了行业默认的基本要求。

Google 将 Kotlin 定为 Android 的主要开发语言后，进入这个生态的开发者自然都会接触并学习 Kotlin。就像 Jetpack Compose 一样，四年前它还是一项比较新鲜的技能，如今已经成为许多岗位的标准要求。Kotlin 也是如此，现在已经成了基本门槛。

真正能够形成差异化的，反而是更深入的专业能力，比如 Kotlin Multiplatform（KMP）。这些技能依然能让一名工程师从庞大的人才库中脱颖而出。相比之下，单纯掌握 Kotlin 本身，如今已经越来越普遍了。

找工作的九条准则

主持人：在寻找下一份工作时，你列出了未来雇主应具备的九项价值观，我们逐个来看一下。

“第一条——不沾 AI。不去 AI 公司，不做基于 AI 的产品，或者不强制在开发中使用 AI。”

Jake Wharton：这条标准排在第一是有原因的，它可能正是我一直在寻找的东西。

如今我们正处于一个技术快速演进的时期，各公司正积极地将 LLM 硬塞进工作流和产品中，而它们往往并不属于那里。

在过去几年里，软件质量并没有出现肉眼可见的改善，我也不认为当前的 AI 工具本质上会随着时间的推移提升代码质量。虽然很多公司高管们把它们看作是加速产出和削减工程成本的捷径，但现实情况往往并非如此。

除了实用性，还存在伦理方面的担忧。这些模型是在侵犯版权的基础上训练出来的。回想一下亚伦·斯沃茨 (Aaron Swartz)，在 2013 年，他因为下载了大约 30GB 的学术论文而面临数十年的监禁，最终选择了自杀。而今天，AI 公司肆无忌惮地抓取受版权保护的书籍、艺术品和获得许可的代码库，将这种访问转化为混搭和重新发布知识产权的特权。最近有报道称，Meta 使用 BitTorrent 下载了大量受版权保护的书籍用于模型训练。领先科技公司对伦理的漠视令人震惊，我拒绝为其添砖加瓦。

这个要求直接淘汰了大约 80% 的潜在机会。这也反映了我在 Block 和 Cash App 的经历。传统上，开发者工具的采用是自下而上的：工程师们对 Kotlin、IntelliJ 或更好的构建系统感到兴奋，然后申请领导层采用它。而在生成式 AI 方面，指令是自上而下的：高管领导层在不考虑工程判断的情况下，强制要求使用特定的工具。

高管们通常不会直接规定工程师是否应该使用静态类型，因为这类问题本质上属于工程决策，应该根据代码的正确性和可维护性来判断。但如果管理层开始强行要求团队使用某些开发工具，尤其是在公司持续裁员的背景下，就容易形成一种不健康的工作氛围。

我也理解为什么公司都在追逐 AI，本质上是在争夺新的竞争优势。单纯从商业角度来看，跟随资本和市场炒作并不难理解。但到了我职业生涯的这个阶段，我已经有了选择的余地，可以决定自己不参与这样的生态。

主持人：“第二条——不沾加密货币。密码学是好东西，但加密货币很糟糕。”

Jake Wharton：在 LLM 出现之前，加密货币曾是科技行业最主要的炒作周期之一。我在 Square 和 Cash App 工作时，公司都非常积极地押注比特币和加密产品。

但从根本上说，我认为加密行业的很大一部分运作方式，更像是一场缺乏内在效用支撑的庞氏骗局。虽然我一直非常支持数据所有权和个人自主权，但加密货币在实际发展过程中已经逐渐演变成了一个具有掠夺性的系统：从散户手中榨取价值，最终让早期参与者和各种投机平台获利。

主持人：“第三条——远程工作。我要远程工作，但很乐意每年去几次办公室。”

Jake Wharton：我从 2015 年起就一直远程工作，回到受办公室束缚的工作模式对我没有吸引力。

我重视面对面的交流。在行业会议上录制这次采访，让我能够与几十位平时可能一年才见一次面的同事重新建立联系。面对面的情谊和共情是很有价值的。但是，我完全没有恢复每天通勤的欲望。有了孩子之后，日程的灵活性变得至关重要。能够围绕家庭生活来平衡工作，这是我不愿放弃的优势。

主持人：“第四条——开源。我使用开源软件，并且会发布自己的开源项目或者想要开始做开源。”

Jake Wharton：开源对我职业发展起到了核心作用。当我在学习开发软件时，开源仓库提供了蓝图。默认把自己的工作公开发布变成了我的第二天性。

在 Square，发布开源库在招聘、代码质量提升和社区参与方面都取得了巨大成功。现代技术完全建立在开源基础上——从 Linux 和 Android 到 SQLite 和 JVM。做出回馈，无论是通过原创项目还是维护外部依赖项，都维系了这种使软件行业得以生存的互惠关系。

主持人：“第五条——客户高于股东。你的产品专注于为客户提供价值，而不是让股东中饱私囊。”

Jake Wharton：今天很少有消费级软件的更新能真正让用户感到兴奋。更多的时候，更新带来的是恐惧：功能被移除，界面退化，或者现有的功能被锁在了付费墙后。

这个过程通常被称为“平台劣质化”。依靠风险投资支持的公司经常通过补贴早期增长来获取用户，一旦增长放缓，就会转向激进的价值榨取。我更喜欢开发那些由可持续商业模式支持的产品，这种模式不会为了满足股东的短期期望而牺牲客户体验。

主持人：“第六条——人高于利润。不要零工或者用剥削性的手段去榨取客户的每一分钱。”

Jake Wharton：这与客户高于股东的理念紧密相连。像 Uber 和 Airbnb 这样的公司，最初利用风投补贴，以低价冲击了成熟行业。曾经打车很便宜，是因为投资者垫付了一半的成本。一旦资金收紧，价格就会恢复正常，甚至达到或超过传统替代方案的水平。

虽然传统的出租车行业存在监管缺陷，但他们提供了保护和结构性的监督。而零工经济在弹性收入的幌子下，将运营成本（如车辆折旧、维护和燃料）转移到了独立承包商身上。我不希望去构建促成这种经济模式的软件。

主持人：“第七条——小而专注。 把一件事做好，胜过试图面面俱到。”

Jake Wharton：我在 Square 和 Cash App 最充实的时期，正是团队规模还很紧凑的时候。小团队能培养出一致性、快速的决策和雄心勃勃的解决问题能力。

到我离开时，这家已经扩张到了大约 12,000 名员工，与我刚加入时的 200 人相去甚远。在这种规模下，毫无疑问，就像在 Google 这样的规模下一样，组织惯性、官僚主义和产品臃肿不可避免地会出现。官僚主义的习惯一旦形成，产品开发就会放缓，领导层就开始拼命寻找能带来用户的新事物。当公司规模较小时，事情比较纯粹；你可以专注于寻找特定的问题领域，并将其执行得异常出色。

我也喜欢做各种不同的事情。当公司变大时，工程师的职责范围往往会急剧缩小。我记得听说五年前 Twitter 的一位工程师仅仅负责私信（DM）的输入框——而且那还是在 Twitter 甚至都没有富文本聊天功能之前；他们的整个工作领域真的就只有那个私信输入区域。这实在是太狭窄了，以至于你失去了享受构建产品不同层面的灵活性。我更喜欢在产品内部自由切换，并在多个领域开展工作的自由。

小团队还提供了多得多的学习机会。当团队很精简且你的职责更广泛时，你会不断地被推离舒适区。你必须学会自己动手做事情，因为那里没有一个专门的 50 人部门，可以让你把需求扔过去，然后等上两个月让他们来交付。你必须事必躬亲。

主持人：“第八条——多元、公平和包容（DEI）。平等地分配机会需要积极的努力。”

Jake Wharton：取决于你居住在哪里、出生在哪里以及你过往的工作经历，生活中的各种因素会赋予你不同的优势和劣势。这超越了性别或种族等显而易见的类别。

回到我在 Cash App 的经历：在讨论薪酬时，在不同国家做着和我完全相同工作的同事，拿到的是当地的“市场价”，这可能只有我在美国收入的一半。这对我来说毫无道理。他们仅仅因为地理位置就受到了惩罚。你会看到人们为了获得更高的薪水而搬到美国，目的只是在做完全相同的工作时拿到更高的报酬。地理差异会让工程师处于严重的劣势，他们的收入少得多，并且可能难以维持他们渴望的生活方式。

除了地理因素，基于人们无法控制的特征来歧视他们是荒谬的。令人沮丧的是，我甚至必须将这一点明确声明为核心价值观，这本应是基本底线。那些反对 DEI 的人小时候真应该多看看《星际迷航》，在那里，跨物种、不同背景的多元化以及性别平等是完全自然的事情。这甚至都不应该再有争论了。鉴于更广泛的针对 DEI 的政治抵制，我觉得非常有必要指出这种抵制是胡说八道，并重申这对我来说依然极其重要。

主持人：“第九条——工作与生活的平衡。我的手机上没有工作聊天软件、工作邮件，也不在手机上做代码审查。”

Jake Wharton：在 Square 的头五六年里，我的手机上装了 Slack 和 GitHub。我根本不觉得在周六晚上跳出来审查一个 Pull Request 有什么不妥。

虽然这对我个人有效，但我最终意识到了这传递出的有害信号。实习生或初级工程师看到你这么做，但他们并不知道背景情况。他们不知道，尽管我周四人在办公室，但我其实请了假，因为我身体不舒服，或者预约了医生，或者只是需要休息。我实际上是在平衡我的工作时间——在某个晚上工作到很晚，是为了弥补周四的休假。或者当我处于心流状态时，我可能会连续工作 12 个小时，直到第二天下午 1 点才打开笔记本电脑。

当初级同事在不知道这些背景的情况下，看到我在周日晚上 11 点审查 PR 时，他们理所当然地会认为全天候工作是公司的期望，并认为他们也必须在个人手机上安装工作应用。在周末快速回答一个工作问题看似无害，但它确立了一个有毒的先例。

随着远程工作和移动设备变得如此强大，保持永久在线变得危险地容易。断开连接具有巨大的价值，我想为其他人树立这种榜样。周五下午 5 点合上笔记本电脑，直到周一早上 9 点再看它，并且手机上没有任何工作的痕迹，这应该是一件完全正常的事情。

主持人：哪些价值观让你损失了最多的工作机会？“不沾 AI”淘汰了 80% 的工作机会——剩下的呢？

Jake Wharton：对我来说，限制选择范围最多的一条要求，就是尽量避开风投（VC）融资的公司。我更希望找到一家已经实现盈利、商业模式健康且可持续、能够创造真实收入的企业，而且它的业务不应该依赖那些自己无法控制、又充满不确定性的外部系统。

如果一家公司的业务建立在第三方平台之上，而这些平台又很容易受到价格暴涨或地缘政治动荡的影响，那么这样的公司本身就很脆弱。按照这个标准，大约 95% 的潜在公司都会被排除在外，因为依靠风投输血已经成了科技行业最常见的发展模式。

当然，也有商业模式健康、风投支持良好的初创公司，只是这样的公司非常少见。另一方面，那些规模较小、完全依靠自身收入维持运营的公司，往往又没有在做真正让我感兴趣的产品。

因此，单是排除依赖风投的公司，就已经让我失去了 90% 到 95% 的选择。这是一个很难坚持的原则，尤其是风投支持的公司通常能提供更高的薪酬。为了坚持自己的价值观，我也必须接受因此带来的降薪。

如何看待用 AI 裁掉 14% 的员工？

主持人：让我们回到 AI 话题。在 2026 年 5 月，Coinbase 首席执行官 Brian Armstrong 裁员 14% 并将其归功于 AI，他的原话中有一句：“非技术团队现在也能够交付生产代码了。”你如何看待这种转变？

Jake Wharton：这并不是我看好的公司，他们几乎违背了我列表上的每一个价值观。Armstrong 所谓的“工作场所不谈政治”政策，本身就是一种极具政治色彩的立场，尤其是当他自己依然可以随心所欲地在 X 上公开发表他的政治观点时。

他的立场极其短视。正如我之前提到的，生成式 AI 领域是由风险资本人为支撑起来的。例如，GitHub 最近将 Copilot 转向了基于用量的计费模式。在原先每月固定 30 美元的模式下，其使用量为了抢占市场份额而获得了大量补贴。现在，随着风投补贴的收紧，一位开发者的 Copilot 账单从 30 美元飙升到了每月约 1400 美元。这种价格通胀将成为整个行业的常态。

那些在结构上对 LLM 产生依赖的公司，将会眼睁睁地看着运营成本飙升一到两个数量级。百倍的成本增长会瞬间粉碎 LLM 可以经济地取代人类软件工程师的论点。当把实际的基础设施支出考虑在内时，LLM 生成代码的最终成本将会高于那些被解雇的工程师。

我对降低技术门槛没有意见。我曾共事过的最优秀的一位设计师，花了一个周末学习 Android，直接在我们的代码库中构建了一个复杂且漂亮的动画，并提交了一个极好的 Pull Request。在负责任的前提下，赋予非工程师权力，让他们做出切实的贡献，这当然是件好事。

而不负责任的做法是，高管领导层说：“我们将解雇一大批工程师，并把他们的工作推给 LLM。” 14% 的裁员相比算温和的了，在我离开 Cash App 后，他们裁掉了 70% 的工程师。高管们以为，他们可以通过要求留下的每个工程师使用 LLM 来完成四个人的工作，从而以更精简的方式运营，同时非技术人员则通过向聊天机器人发送提示词来生成代码请求，却根本不理解代码。这在短期内或许看似奏效，但这注定会导致软件质量在长期内退化。

成本清算是数学上的必然，而不是主观意见。AI 领域正在套用经典的风险投资剧本：补贴使用量以套牢客户，然后转向激进的价值榨取。当价格恢复正常时，那些押注用 AI 替代工程师的公司将自食其果。

主持人：你尝试过使用 AI 智能体写代码吗？

Jake Wharton：绝不。我刻意采取这种毫不妥协的立场，是因为人们需要去面对这些工具背后的真相。

科技工作者过去之所以抗拒成立工会，是因为薪酬丰厚，福利奢华。现在资本收缩了，员工在一夜之间就被抛弃了。我们现在是在德国录制这段采访，这里有健全的劳工保护。而在美国，你甚至还不知道自己被解雇了，公司账号就已经被切断了——你的邮件直接停止同步了。依赖 AI 工具会加速这种演变动态，它将话语权从工程师手中夺走，把开发者变成一次性的齿轮，让公司用更廉价的自动化代理来替换他们。

这里有两个维度：伦理和责任。负责任地使用 LLM 的方式，是将其作为辅助的助推器——加速你已经完全理解的任务。不负责任的方式，是用它来编写超出你技术能力范围的代码，生产出离了工具你就无法维护的系统。如果 Token 价格暴涨二十倍，你只能负担得起以前使用量的一小部分，你是不是突然就无法胜任你的工作了？

我保持强硬立场，是希望当当前的炒作泡沫破裂时，整个行业能经历一次集体洗牌。AI 不会消失，但开发者必须避免将他们的核心工程能力建立在自动统计学的基础之上。AI 应该只是工具箱里的辅助工具，而不是工程理解力的替代品。

主持人：如果六个月后 AI 写的代码比你的更好，你的 B 计划是什么？

Jake Wharton：我会继续选择规模更小的公司，哪怕因此少赚一些钱，只要能换来自己真正想要的工作状态和生活，我觉得是值得的。

我现在并不是处在职业生涯刚起步、需要不断向上攀爬的阶段。幸运的是，我已经有了一定的财务安全感，这让我有底气做出这样的选择。当然，这本身也是一种奢侈。

另外，我也不认为 AI 在短期内就能超过真正有经验的工程师。现在的 LLM 主要是基于 2022 年之前人类产生的大量数据训练出来的。哈佛等机构的研究表明，如果不断把模型自己生成的内容作为训练数据，反馈给下一代模型，经过反复迭代，最终很容易出现所谓的“模型崩溃”。

更重要的是，我并不认为 LLM 真正理解自己生成的内容。它们本质上仍然是进行统计预测的系统，并没有真正理解设计决策背后的原因。开发者平时也会调试那些从 Stack Overflow 复制来的代码，因为即使是获得大量点赞的答案，也可能隐藏着一些不容易察觉的问题。AI 生成的代码同样无法摆脱这种概率性的缺陷。

所以，我认为软件开发始终需要真正理解系统运行原理的工程师。无论工具怎么变化，这种理解本身都不会消失。

Kotlin 的黄金时代结束了吗？

主持人：Kotlin 最初是作为 Java 的“样板代码杀手”出现的。既然 AI 擅长生成样板代码，AI 难道没有抵消掉 Kotlin 的主要优势吗？

Jake Wharton：Java 语言架构师 Brian Goetz 经常强调，代码被阅读的次数是编写次数的十倍。

敲打样板代码从来都不是编程中最难的部分。最难的部分发生在那之前：构思系统架构，定义接口边界，以及对复杂的业务领域进行建模。第二难的部分发生在之后：长期维护。代码的生命周期长达数年，漏洞会出现，需求会变化，系统必须进行调整。

减少样板代码——简洁的属性声明、尾随 Lambda 表达式、优雅的 DSL（领域特定语言）——仅仅是为了在演示幻灯片上向开发者介绍 Kotlin 的噱头。一门语言真正的长寿，取决于它能多有效地支持代码库的长期演进。这需要复杂的工具生态和富有表现力的类型系统，而不仅仅是少敲几下键盘。使用 AI 生成重复的样板代码可以帮助克服写作卡壳或更新重复的调用点，但它并不能解决软件工程的核心挑战。

主持人：Java 已经添加了 records 和 sealed classes。随着特性差距的缩小，Kotlin 的黄金时代结束了吗？

Jake Wharton：Java 值得称赞，它将其发布节奏加快到了六个月，并引入了实验性的预览特性。事实上，Java 最近添加的一些特性——比如 records——在实现时具有比 Kotlin 等效特性更高的架构连贯性。因为 Kotlin 必须在 Android 上保持与传统的 Java 1.6 字节码兼容，所以诸如数据类（data classes）等特性必须被编译成带有合成方法的标准类。相比之下，Java 可以引入新的 JVM 字节码并同步更新虚拟机。为了保持竞争力，Kotlin 必须继续采用现代的 JVM 原语。

主持人：Kotlin 在根本上仍然比 Java 做得好的是什么？

Jake Wharton：空安全（Null Safety）。Tony Hoare 曾把空引用称为他“价值十亿美元的错误”。但真正的问题并不是数据可能缺失，毕竟在很多场景下，我们确实需要表达“没有值”这种状态，而是这种状态没有被纳入类型系统。

在传统 Java 中，任何引用类型默认都可能为空。开发者可以忽略这种可能性，直到程序运行时因为空引用而崩溃。

Kotlin 则把可空性直接纳入了类型系统。开发者必须通过问号显式声明一个值是否可以为空，这样编译器就能在程序运行之前发现并阻止一大类潜在的空指针错误。这种在编译阶段就能获得的安全保证，到今天依然是 Kotlin 相比 Java 的一个巨大优势。

主持人：Kotlin 和 Swift 主导着移动端开发。Swift 在哪些方面做得比 Kotlin 更好？

Jake Wharton：我非常喜欢 Swift 这门编程语言。与 Kotlin 必须保持与传统 Java 代码的向后兼容性并编译为 JVM 字节码不同，Swift 没有任何历史包袱。虽然 Swift 保持了与 Objective-C 的互操作性，但苹果能够从零开始设计其语言特性、功能和编译策略，而不受传统运行时表示形式的束缚。

Swift 中的错误处理是一项真正的一等语言特性。它迫使你显式地处理可能抛出异常的函数，这与 Kotlin 在其类型系统中强制执行空安全的方式非常相似。相比之下，Kotlin 处理异常的方法基本上形同虚设。Kotlin 运行在 JVM 上，而 JVM 有自己的异常模型，Java 同时拥有受检异常和非受检异常。Kotlin 基本上认定，既然它运行在 JVM 上，就必须使用异常，但它把所有的异常都变成了非受检异常。

这是 Kotlin 中真正的痛点之一：你很难检查你正在调用的函数的失败模式。Kotlin 语言演进中一个主要且持续的讨论是，如何对函数的潜在失败进行建模（比如将字符串解析为数字），从而迫使调用者在编译时处理潜在的失败状态，而不是在代码库中留下运行时地雷。在 Swift 中，抛出异常的函数会被显式标记，要求你必须显式地处理错误，或者刻意使用 try 操作符。

Swift 脱颖而出的另一个领域是它的内存表示和编译为原生代码的能力。Swift 拥有真正的结构体（structs）和紧凑、连续的内存表示。相比之下，Kotlin 继承了 JVM 的对象模型，其中一切都是在堆（heap）上分配的类实例，字段通过指针间接（pointer indirection）访问，并且对象布局在内存中是碎片化的，而不是整齐地排列在 CPU 缓存行（cache lines）中。这种底层数据表示方式带来的性能瓶颈挣扎，是这两种语言之间另一个明显的对比点。

主持人：那反过来看，Kotlin 在哪些方面做得比 Swift 更好？

Jake Wharton：这个问题很难。在许多方面，Swift 是一门比 Kotlin 设计得更好的语言，在纯粹的语言特性上，Kotlin 并没有多少绝对优势。

Kotlin 真正的优势在于次级层面：生态系统、开源库，最重要的是工具链。在 IntelliJ IDEA、Android Studio 和现代构建系统的支持下，Kotlin 的开发者工具遥遥领先于 Xcode。在 Xcode 中重构大型 iOS 代码库简直是件痛苦的事。Xcode 花了数年时间才引入基本的重命名重构功能，而这实际上是 IntelliJ 二十年前最早具备的功能之一。当 iOS 开发者为这个新功能的加入而欢呼时，我为他们感到高兴，但这毕竟是我们二十年前就已经享受到的功能。

如果仅仅看语言语法，Kotlin 并没有比 Swift 高出一大截。提升 Kotlin 地位的是它周围的一切。你可以设计出世界上最好的语言，但如果没有成熟的 IDE、库、构建工具和静态分析，你将很难推动它的普及。Kotlin 和 Swift 都是极好的语言，但 Kotlin 的工具生态系统提供了高效得多且令人愉悦的开发体验。

主持人：你提到了错误处理和失败模型。在你看来，哪种编程语言处理错误最好？

Jake Wharton：我认为是 Rust 做得最好。Rust 中的许多设计决策与我大脑的运作方式感觉非常契合。直接在类型系统中表示可选性和易错性，正是软件应有的建模方式。

Rust 迫使你直面所有权、借用和资源生命周期——例如，显式地明确谁负责关闭一个文件描述符。这让我产生了深深的共鸣，很大程度上是因为多年来在缺乏那些编译时保证的语言中工作所留下的“伤疤”，这些缺失导致了内存泄漏、未关闭的文件描述符、空指针异常，以及非受检异常引发的意外运行时崩溃。当你反复经历这种痛苦时，你就会开始寻找更好的范式。Rust 是一门要求很高、学习曲线陡峭的语言，但一旦你跨过了最初的门槛，它的概念便与严谨的工程实践完美契合。

主持人：你会在什么场景下选择不使用 Kotlin？

Jake Wharton：我在日常工作中写了大量的 Kotlin 代码，所以当我在做业余项目时，我更喜欢探索一些完全不同的东西。最近，我一直在鼓捣微控制器和嵌入式设备。这些是内存极其有限的环境。虽然在技术上你可以用 Kotlin 编写目标为这些设备的代码，但这门语言并不是为这种限制而设计的；它期望底层有一个完整的操作系统。对于裸机嵌入式编程，Kotlin 实在太重了。

我也不喜欢在 Web 开发中使用 Kotlin。如果你已经有了一个现有的 Kotlin 代码库，并且想要共享业务逻辑以建立单一事实来源，那么编译为 JavaScript 或 WebAssembly 是一个显著的优势。然而，如果我是从零开始构建一个 Web 应用程序，Kotlin 不会是我的首选。Compose HTML 并没有真正尊重 Web 的工作方式。如果你完全是为 Web 构建应用，Compose UI 或 Kotlin 不是自然而然的起点。你会选择 Web 原生工具。Kotlin 在 Web 上的优势，纯粹是作为现有逻辑的一种增量共享机制。

个人开发习惯与经验

主持人：你个人的开发环境配置是什么？IDE、插件、工具？

Jake Wharton：非常极简。基本上就是原版的 IntelliJ IDEA 或 Android Studio，具体取决于我在做什么项目。至于插件，非常少。我通常会装 SQLDelight 插件，这是我参与开发的一个 SQL 工具库。

在 IDE 之外，我使用 Ghostty 终端模拟器。虽然 IDE 中新的内置终端非常好，但我还是保持着开一个独立终端的习惯。我也会开着 Firefox 浏览器查看技术文档。这就是我整天按 Alt-Tab 切换的三个东西。

主持人：Firefox，而不是 Google Chrome？

Jake Wharton：是的，这又回到了伦理问题。实际上，最初正是浏览器市场的良性竞争成就了 Chrome 的伟大。但他们活得太久，最终变成了“恶龙”。他们占据了不成比例的市场份额，现在是在对 Web 生态系统进行强权压迫，而不是建设性地参与其中。

主持人：在 Kotlin 社区有一句名言：“当 Jake Wharton 的代码编译失败时，这意味着编译器有 Bug。”你是如何看待这种名声的？

Jake Wharton：关于这个我有个有趣的故事。当我在 Google 工作时，某个 Subreddit（Reddit 的子版块）修改了它的 CSS，导致每个评论者的用户名都显示为我的名字。Google 里有些不懂这个 CSS 玩笑的同事，截了一些据称是我写的、攻击 Google 产品的煽动性评论的图——这些话我从未说过，也绝不会说。他们把这事升级汇报给了我的经理，结果我不得不在一个会议上向我经理的经理去解释 Reddit 的 CSS 是怎么运作的，并且澄清那些话不是我说的。

我很幸运能通过开源库和会议演讲取得一些成功。有些人喜欢拿这个梗开玩笑，我当然对此完全不介意。

主持人：你做 Android 开发者已经快二十年了。是什么让你没有职业倦怠？

Jake Wharton：在第一个十年里，Android 和移动开发快速演变成为了我们今天所依赖的平台。每一届 Google I/O 大会都会引入令人兴奋的新功能，那种发展速度维持了我的热情。

然而，在过去的十年里，平台更新的方向发生了转变。就像消费者软件更新一样，平台的变化往往会引发恐惧：“他们现在又要拿走什么功能，或者又要强加给我们什么？”

为了保持活力，我把我的好奇心转向了其他地方。我一直在构建定制硬件。开发移动软件很有成就感，因为你可以立即将应用部署到手机上，但物理硬件引入了另一个维度的真实感。硬件是摸得着的、物理的，并且能在六英寸的玻璃矩形之外与环境进行交互。

我也会学习其他编程语言。当开发者问及如何在 Android 或 Kotlin 上精进时，我的首要建议是去学习一门完全不同的语言。探索 Swift、Rust、Zig、C 或 Haskell 并不是为了在职业上精通它们；而是为了扩展你的心智模型。

像 Haskell 这样的语言从根本上重塑了你对数据建模的认知方式。你在其他生态系统中吸收的模式不可避免地会提升你在 Kotlin 或 Java 中的日常工作。当你遇到架构挑战时，你会认出它：“我见过 Zig 或 Swift 是如何处理这个问题的，我理解其中的权衡。”

它拓宽了你的工程视野，就像大学要求学习人文学科、数学和科学，以培养全面发展的能够解决问题的人才一样。探索不熟悉的语言可能会让人感到不适，但有数以百万计的工程师都在高效地使用它们编写代码。

我倾向于将新语言与实际的业余项目结合起来。例如，我很讨厌我家里草坪洒水系统的商用控制器。从机械原理上讲，它只不过是一个驱动 20 个继电器的微控制器。我以此为契机，用树莓派构建了定制硬件，并用 Rust 编写了固件。拥有解决个人问题的内在动机可以防止拖延，并将学习变成真正的消遣。

这种好奇心又反哺了我的日常工作。作为操作系统的 Android 让人感觉基本上已经成熟和完备了，但 Kotlin 依然非常吸引人——特别是随着 K2 编译器的稳定和语言特性的不断推进。

对于那些想要防止倦怠的开发者来说，完全远离电脑是一种健康且有效的方法。但对我来说，编程仍然是一门能带来真正快乐的手艺。在我的日常技术栈之外寻找灵感，能让这门手艺保持新鲜。

主持人：你认为每个开发者都应该学习一门以上的编程语言吗？

Jake Wharton：绝对的。你不需要同时学习六种语言，但避免把自己局限在单一语言里，是非常重要的。精通一门语言当然很有价值，但不同语言之所以存在，是因为它们做出了不同的设计取舍。理解这些取舍，能够拓宽你的技术视野。

Rust 就是一个很好的例子。它的设计初衷之一，就是消除 C 和 C++ 中常见的内存安全和并发问题。学习 Rust 的所有权和借用规则，会从根本上改变你编写 Kotlin 和 Java 的方式。你会开始思考一些以前可能不会特别关注的问题：这个对象到底由谁负责？当我把一个引用传递给函数时，我是在转移所有权，还是只是暂时借用？这个资源最终由谁负责关闭？

大多数语言都无法在编译时对所有权进行明确建模，但理解这一概念，能够帮助你发现隐藏在架构中的风险。否则，一些没有被明确表达出来的约定，很可能在未来的维护过程中导致内存泄漏，或者让资源被过早释放。

同样，Java 和 Kotlin 开发者通常不需要经常考虑底层的内存布局，或者 CPU 缓存未命中会带来什么影响。但当你开始编写 C、Zig 或 Rust 时，就不得不面对这些问题：数据在内存中是如何连续布局的？一次指针间接访问又意味着什么？

这时，你可能会突然理解一些以前只是停留在结论层面的性能差异。例如，为什么某些原生二进制程序可以比 JVM 字节码快很多？其中一个原因就在于，底层语言可以更直接地控制数据布局和内存访问，减少大量指针追踪带来的 CPU 缓存压力。

所以，接触不同的编程语言，并不意味着你一定要把每门语言都学到精通。更重要的是，它们会迫使你从不同角度思考同一个问题，而这些洞察，往往是只停留在自己的主力技术栈里很难获得的。

开源

主持人：如今 Kotlin 在更广泛的开源生态系统中的地位如何？

Jake Wharton：Kotlin 从与 Java 庞大的开源生态系统的双向互操作性中获益匪浅。当我们用 Kotlin 重写 Okio 和 OkHttp 时，一些纯粹主义者感到很沮丧，因为这引入了对 Kotlin 标准库的依赖。然而，我们保持了严格的二进制兼容性：将 OkHttp 作为传递依赖项使用的应用程序可以继续运行，而不会出现编译或运行时中断。

Kotlin 的开源优势源于 JetBrains 的一个决定：完全在公开环境中开发语言、编译器和演进过程。相比之下，苹果最初是在闭门状态下开发 Swift，在 WWDC 上发布经过打磨的年度版本，之后才逐渐转向开放治理。

因为 Kotlin 在推出时就带着开放的精神，并且扎根在一个已经沉浸在开源库中的 Android 社区，它的生态系统立刻繁荣了起来。一旦 Kotlin Multiplatform 成熟，开发者们就迅速发布了解决基础跨平台需求的各类库。Kotlin 的开源生态系统是当今软件开发领域中最健康的生态系统之一。

主持人：开源依赖会引入风险。一些开发者认为，严重的外部依赖是危险的。Ghostty 的作者 Mitchell Hashimoto 最近写了一篇文章，谈论如何将依赖代码直接纳入项目或分叉，并冻结更新。你对依赖管理有什么看法？

Jake Wharton：依赖是一把双刃剑。利用外部代码可以加速交付，但糟糕的集成会将你的应用程序与第三方的决策紧密耦合在一起。当维护者做出破坏性变更或更改许可证时，下游的使用者往往会感到措手不及。

根本问题在于人们普遍误解了采用开源软件意味着什么。当你引入一个库时，你就承担了对该代码的全部责任，就好像是你自己写的一样。最终用户根本不在乎你依赖了哪些库；他们只体验最终的产品。

开发者经常把开源依赖当成遥远的黑盒，觉得他们需要公司特别的批准才能去修复上游库中的 Bug。如果你不使用这个库，你原本也是要在内部编写这些代码并负责维护的。向上游贡献修复代码应该成为一种默认的心态。以积极的“主人翁精神”对待依赖，可以让你预见破坏性变更，参与讨论，并确保库能够建设性地演进。

有些人认为大语言模型（LLM）消除了对库的需求，因为 AI 可以按需生成样板化的工具代码。这种观点忽略了共享开源代码库的复利价值。当成千上万的工程师在加固（harden）一个库时，边缘情况的 Bug 和微妙的竞态条件在你遇到它们之前就已经被解决了，而且性能优化会同时惠及所有使用者。共享的开源代码库代表了累积的集体工程智慧，这是单一提示词生成器无法复制的。

主持人：既然你从事过专业的开源工作，是什么动机促使公司投资开源软件？

Jake Wharton：在公司的资产负债表上量化开源是一件很有挑战性的事情。发布并维护一个生产级的库需要相当大的开销：全面的文档、严格的测试覆盖率、自动化发布流程以及问题分类。

然而，开源带来了巨大的招聘和声誉价值。发布高质量的库标志着一种成熟的工程文化。从历史上看，像 Square、Google 和 Meta 这样的公司之所以能招募到顶尖人才，正是因为开发者们钦佩他们所创造的开源工具。

但现在情况不完全是这样了，这取决于你关注的领域。除此之外，作为一名工程师，向人们展示你正在做的工作，而不是仅仅口头讲述，感觉是很棒的。只能说：“我构建了这个了不起的东西，能让你以一种有趣的方式使用这项技术，但它被锁在我们的专有代码库里，我需要在公司笔记本电脑上进行双重认证才能访问它”，这与把它放在 GitHub 上说：“来看看这个，看看你能怎么用它，并在它的基础上进行开发”是截然不同的。围绕后者，存在着一种真正发自内心的兴奋感。

归根结底，作为一名工程师，能够做到这一点是很有成就感的，尽管这并不适合所有人。你不应该强求。当讨论我们在“为积极参与开源的公司工作”方面的价值观时，你不应该抱有这样的态度：“我们必须开源一些东西，仅仅是为了让我们的工程组织看起来很厉害。”这是错误的做法。这看起来很虚伪，即使你不直说，人们也能感觉得到。当你构建了一个干净、可重用、且能让他人受益的组件时，你自然会知道。即使一个项目很小众，其他人可能不会立刻使用它，把它公开出来也没有任何坏处，而且还能展示有趣的技术成果。这能给那些喜欢谈论自己作品的工程师带来快乐。

当然，有些人宁愿不参与。他们不想要一个公开的 GitHub 主页，也不想承担处理外部互动的负担——比如用户抱怨说“你们移除了这个功能，搞崩了我们的应用”，或者要筛选那些未经请求的、由 LLM 生成的拉取请求（Pull Requests），亦或是与那些想把库带向你不希望的发展方向的贡献者进行辩论。这些人与人之间的互动和沟通挑战，往往还会因跨国语言障碍而变得更加复杂，有时会非常困难。但对于特定类型的工程师来说，这种动态互动是充满动力和乐趣的。

从务实的角度来看，当你离开一家公司时，你开源的任何代码都是你在下一份工作中可以继续使用的代码。我自己的人生轨迹就是这样：我构建并开源的作品，没有一个是被迫废弃的。

主持人：很多人认为开源主要是不计报酬的志愿工作。现代开源软件中，有多少实际上是有资金支持或基于合同的？

Jake Wharton：这里有几个不同的类别。现代开源工作中，有很大一部分是隐性的公司赞助，仅仅是因为公司雇用了全职人员来开发这些项目。我曾任职的公司组织下的库几乎都是这样诞生的。我是在正常的上班时间开发它们的。即使是在处理外部的功能请求或对并不直接影响我们内部代码库的 Bug 进行分类（triage），在工作时间做这些也是被允许的。

真正有问题的情况出在那些在公司代码库之外构建的个人业余项目上，这些项目最终成为了其他公司代码库中“承重的基础设施（load-bearing infrastructure）”。我开源这些项目是因为我喜欢展示我的工作，并让其他人在此基础上构建。然而，它们是在标准许可证（通常是 Apache 2.0 许可证）下发布的，该许可证明确声明不提供任何合同、担保或保证。

行业很难区分一个人是在业余时间折腾个人仓库，还是一名工程师在发布由公司支持的库。当个人仓库的个人维护者不堪重负或跳槽时，项目通常就会落入无人维护的境地。我们缺乏一个可持续的模式，让严重依赖这些关键依赖项的企业能在资金上予以回馈。

资金支持并不是唯一的选择；贡献工程力量同样有价值。公司可以不提一个要求新功能的 Issue，而是问：“我们能不能自己开发这个功能并提交一个 PR？” 然后自己去完成工程上的跑腿活儿。或者，帮助分类问题或修补上游 Bug，可以减轻个人维护者的基础维护负担。这种工程时间也是一种支付方式。

理想情况下，我们应该有更好的机制来确保开源维护者获得报酬。那些被价值数十亿美元的大企业所依赖的关键软件，往往是由全凭热情的个人在独自维护的。虽然在一个应用程序的开源致谢名单中看到你的名字，或者在会议上听到用户的反馈很有成就感，但仅仅是认可并不能用来支付账单。资金报酬能让这种维护变得可持续，而不是迫使维护者因为责任感而牺牲个人时间，或者从他们的日常工作中挤出时间。

没有创造者的 Kotlin，未来会如何？

主持人：Kotlin 最初的首席设计师 Andrey Breslav 在 2020 年离开了 JetBrains。一门编程语言在没有了最初创造者的情况下，还能成功演进吗？

Jake Wharton：一门编程语言的生命力，必须能够超越它的创造者。像 Andrey 这样的人，把生命中的十年投入到一项成功事业的建设中，之后选择开启新的事业，这完全合情合理。幸运的是，他的离开并没有引发什么波澜，这也充分说明，围绕 Kotlin 建立的治理机制和开发流程已经相当完善。

这样的交接是健康的。如今，大多数主流现代编程语言已经不再依赖某一个“终身仁慈独裁者”（BDFL），而是采用共享的组织架构，与社区共同推进语言的发展。

Zig 目前仍然拥有一位活跃的创造者 Andrew Kelley，但这门语言还很年轻。在这个阶段，由单一决策者掌握最终决定权其实有一定优势。比如，Andrew 可以决定重构整个 I/O 范式，将隐式依赖改为显式依赖，甚至有意打破现有 API，而这些改变正是 Zig 在正式稳定之前所需要的。

但随着 Zig 逐渐逼近 1.0 版本，将这部分治理权逐步交给 Zig 软件基金会将变得至关重要。这样既能减轻 Andrew 身上的巨大负担，也能让 Zig 在未来不受单一个人事变动的影响，保持长期稳定的发展。

主持人：你个人有去塑造过 Kotlin 吗？无论是通过特定的语言特性还是设计决策？

Jake Wharton：我倾向于认为，自己推动了一些事情朝着特定的方向发展。其中有一个变化尤其让我感到兴奋——而且最初我以为它永远不会发生——那就是让 when 表达式默认变为穷举式（exhaustive），要求必须处理所有分支。

当你在其他语言中体验过穷举式模式匹配后，就会意识到它有多么宝贵：当你向密封接添加新的子类，或者新增一个枚举变体时，编译器应该立即高亮显示所有尚未处理的分支，而不是等到运行时才默默地穿透或崩溃。

回想我在 Square 工作的时候，我们曾经编写过编译器插件和相关工具，专门用来强制执行穷举式的 when 表达式。后来，在领导层从 Andrey Breslav 过渡到 Roman Elizarov 的过程中，我和 Roman 讨论过这件事。他当时确认，他们计划直接在语言层面实现这一功能。

虽然我不敢说自己对某个具体的语言特性拥有直接的所有权，但 Kotlin 依然让我持续投入的一个原因，是 JetBrains 的设计选择始终与我的价值观保持一致：在必要时提供编译器级别的安全保障，同时把适当的灵活性和责任交给工程师。

目前，Kotlin 社区正在推进一项关于错误和异常处理的提案，而且最近刚刚进行了更新。我打算对这份提案提供反馈，也鼓励其他开发者参与进来。这是因为，大多数生产代码库都是闭源的，语言设计者无法直接看到团队究竟如何应用各种设计模式，也很难了解他们在哪些地方遇到了阻力。除非开发者主动参与讨论——无论是审查 KEEP 提案、观看 KotlinConf 上关于语言演进的演讲，还是参与 Kotlinlang 的 Slack 频道。哪怕只是简单留下一条留言，说明某个提案为什么会对你的工作流有帮助，或者为什么反而会造成影响，这本身也是在积极参与并塑造这门语言的发展。

主持人：如今主要由谁在主导 Kotlin？是 JetBrains、Google，还是更广泛的社区？

Jake Wharton：应该是三方共同主导。也正因为如此，Kotlin 才会从 JetBrains 单独主导，转向由独立的 Kotlin 基金会负责治理。这种架构的核心，就是避免任何一家机构拥有单方面的控制权。

虽然社区并没有在基金会董事会中获得正式席位，但从规模来看，社区成员的数量远远超过 JetBrains 和 Google 工程师的总和。只要领导团队能够正常运作，就应该把社区反馈充分收集、归纳，再转化为具体的语言设计和演进方案。

这套治理方式也回应了 Google 过去的顾虑。此前围绕另一家公司控制的 Java API，Google 曾经历过旷日持久的诉讼，因此在将 Kotlin 作为一等语言之后，Google 同样需要确认：自己不会再次陷入由某一家企业掌控核心技术所带来的风险。因此，理想状态下的 Kotlin，并不是由某一家公司说了算，而是由 JetBrains、Google 和 Kotlin 社区三方共同推动。

主持人：如果 Kotlin 消失了，软件世界会失去什么？

Jake Wharton：这将是一个重大损失，但语言并不需要永久存在。虽然 Kotlin 远未走到生命周期的尽头，但一门语言并不需要无休止地扩展以去适应每一种能想到的范式。如果未来编程范式发生根本性转变，变成了那种使得 Kotlin 不再是合适工具的状态，那也是一种自然的演进。

主持人：那你个人会失去什么？

Jake Wharton：我大概会丢掉饭碗。我对其他现代技术栈还不够精通，无法获得同等的职业机会。我实际上已经把所有的鸡蛋都放在了 Kotlin 这个篮子里。我非常高兴能把自己的职业生涯与 Kotlin 绑定在一起，所以我当然希望它能一直发展下去！

完整视频：https://www.youtube.com/watch?v=9WjPdgOK-68