在软件行业普遍押注 AI 的当下，公开表示“坚决不用 AI 编程”，几乎等于主动缩小自己的职业选择。
但 Jake Wharton 还是这样做了。
这位被国内开发者称为“J 神”的 Android 与 Kotlin 开源大神，在寻找新工作时列出了九项择业标准，其中第一项就是：不加入 AI 公司，不参与以 AI 为核心的产品，也不接受公司强制工程师使用 AI。按照他的估算，这项要求直接排除了约 80%的潜在雇主。
Wharton 并非没有选择。他称，目前美国资深 Kotlin 工程师的基本年薪通常从 20 万美元起，还可能获得每年约 10 万美元、分四年归属的股权。进入 AI 等热门行业，回报可能更高，但风险也更大。年轻时，他愿意用股权押注未来；现在，他更看重稳定的现金收入，以及选择雇主的自由。
这种态度也延续了他离开大公司的原因。Wharton 承认，Google 的 Android 团队非常优秀，但他不喜欢 Google 通过产品和服务将用户锁定在自有生态。公司规模扩大后，官僚主义增加、产品迭代放缓，管理层也更急于寻找新用户和收入。相比之下，他更愿意留在目标明确的小团队。
Wharton 对硅谷风口的态度近乎尖锐。他认为，加密货币“基本上已经变成了一种庞氏骗局”，没有创造多少真实价值；而大语言模型不仅伴随着版权和开源许可证争议，也正在以一种反常的方式进入软件开发：过去，新语言、新 IDE 和新工具通常由工程师自下而上推动，如今却是管理层绕过工程判断，要求所有人必须使用 AI。
他至今没有使用过 AI Agent 写代码。在他看来，AI 可以帮助工程师处理重复劳动，但最不负责任的用法，是让 AI 生成超出使用者能力范围的代码。如果没有大模型就无法完成任务，开发者往往也无法真正理解、验证和维护结果。一旦形成依赖，工程师交出去的不只是部分工作，还包括自己的能力和议价权，最终可能变成一枚更容易被低成本替换的齿轮。
Wharton 并不认为 AI 会消失，也不担心程序员很快失去位置。“AI 已经强大得令人不安”，但这并不意味着它能够稳定、无误地承担整个软件工程过程。对他而言，AI 最多只能是工具箱中的一件工具，而不能成为工程能力的地基。
从拒绝 AI、质疑加密货币，到讨论 Kotlin 是否仍有优势、为什么更喜欢 Rust，下面是 Jake Wharton 在近期的一场两小时访谈中的完整回答。
Kotlin 像是“Java 十年后想要成为的样子”
主持人：Java 当年已经是全球最主流的编程语言，Android 也建立在 Java 之上，为什么还需要 Kotlin？
Jake Wharton：Kotlin 出现时，Java 语言的发展正处于一个相对停滞的阶段。当时 Oracle 正在逐步接手 Java，版本发布周期仍然长达两年。对于 Android 团队来说，能够使用的语言特性很大程度上受限于 Java 本身。
与此同时，Java 生态之外的编程语言正在快速演进，出现了许多开发者想要的新特性。社区也开始尝试其他选择，有人使用 Scala，也有人使用 Groovy。大家都在期待一种更加现代的语言，Kotlin 正好出现在这个时间点。
JetBrains 本身是一家开发工具公司，因此能够在推出新语言的同时，提供 IDE 和周边基础设施。这让 Kotlin 比那些需要从零建立工具链的语言更容易被开发者接受。
更重要的是，采用 Kotlin 并不意味着抛弃原有的 Java 代码和库。开发者可以继续使用已有的 Java 生态，在原有项目中逐步引入 Kotlin，再慢慢完成迁移。这种渐进式兼容能力，是 Kotlin 得以普及的重要原因。
主持人：你后来成为了 Google Kotlin 团队的第一位工程师，这个机会是怎么来的？
Jake Wharton：在加入 Google 之前，我已经在 Square 工作了五六年。大约在那之前三年，我们开始在公司内部采用 Kotlin。
为了获得公司批准，我写过一份文档，解释为什么我们应该使用 Kotlin。由于其中的论证并不只适用于 Square，我后来将这份文档公开了。它在一定程度上推动了 Android 社区对 Kotlin 的兴趣，我也因此越来越深入地参与 Kotlin 相关工作，并不断向开发者推广这门语言。
随着社区关注度上升，Google 内部的一些人也逐渐意识到，Kotlin 可能会给 Android 开发带来很大帮助。当时我认识的一些 Google 员工开始暗示，Google 可能会正式支持 Kotlin，并询问我是否愿意参与。
对我来说，没有什么比加入负责整个 Android 工具链的公司，并推动 Kotlin 成为 Android 官方一等语言更大的认可了。这个机会几乎不可能拒绝。
主持人：Google Android 团队当时对采用 Kotlin 有没有抵触？
Jake Wharton：与其说是抵触，不如说是谨慎。当时 Android 已经围绕 Java 构建了大约十到十二年，Java 深入整个技术栈，团队对它也非常熟悉。相比之下，Kotlin 还是一门相对年轻、尚未得到充分验证的语言，大概只稳定了一两年。
因此，采用 Kotlin 确实存在风险，团队内部也有顾虑。Google 并非完全厌恶风险，但必须确认各方面都考虑周全。
Kotlin 的引入过程非常审慎，并不是一夜之间完成硬切换。Android 团队最初会为 Kotlin 单独构建配套库，而不是立即用 Kotlin 重写已有的 Java 库。开发团队也不需要一次性改造整个代码库，而是可以逐步采用。
从另一个角度看，这也证明了 Kotlin 对 Java 传统的尊重。它允许开发者在不推翻现有系统的情况下慢慢迁移。
主持人：Kotlin 是否只是一门用于 Android 开发的语言？
Jake Wharton：最初几年，由于 Kotlin 在 Android 社区获得了大量支持，外界形成了一种错误印象，认为它是一门专门为 Android 设计的语言。当时甚至出现过文章，声称 Kotlin 是 Google 为 Android 创造的，这显然并不正确。
后来，Kotlin 开始进入更多领域。过去可能会使用 Java 构建的后端服务，现在也越来越多地采用 Kotlin。Spring 等公司提供的许多能力，也开始优先考虑 Kotlin。
JetBrains 还在持续推动 Kotlin Multiplatform，因此现在也能在 iOS 和桌面应用中看到 Kotlin。比如用于管理和安装 JetBrains IDE 的 Toolbox App，就是一个使用 Kotlin 构建的桌面应用。
Android 更像是 Kotlin 进入其他生态的催化剂。以 Square 为例，我们最初只获准在 Android 项目中使用 Kotlin。但后端的 Java 工程师看到移动团队对 Kotlin 的热情后，也开始希望使用它。后来，Kotlin 逐步被批准用于后端服务。
主持人：如果让你用一分钟向 Java 开发者推荐 Kotlin，你会怎么说？
Jake Wharton：Kotlin 很像是“Java 十年后想要成为的样子”。
Java 必须尽量避免破坏已有代码，因此语言演进速度相对缓慢。很多未来可能进入 Java 的现代语言特性，现在已经可以在 Kotlin 中使用。
采用 Kotlin 也不要求项目运行在最新版本的 JVM 上。现实中还有许多代码库停留在 Java 8 或 Java 11，Kotlin 同样兼容这些环境。开发者可以在较老的 JVM 上，使用更现代的语言能力。
主持人：现在有哪些大型公司在生产环境中使用 Kotlin？
Jake Wharton：Meta、Google 和 Amazon 都在使用 Kotlin。最初的应用主要集中在移动端，但现在后端服务也越来越多地采用 Kotlin。
这些公司还在投入相关工具。例如，就在我们录制这期节目这一周，Meta 将自己的 Kotlin 格式化工具贡献给了 Kotlin Foundation，它未来可能成为 Kotlin 官方的格式化工具。
这些公司拥有世界上规模最大的代码库。它们能够在既有语言和系统之上逐步引入 Kotlin，并且愿意进行长期投入，本身就是对这门语言的一种验证。
谷歌令人生厌之处——把用户锁在自家生态里
主持人：Google 是很多工程师心目中的理想雇主，你为什么工作两年九个月后就离开了？
Jake Wharton：加入 Google 之前，我在 Cash App 工作。我们推动了 Kotlin 的采用，也用 Kotlin 编写了不少开源库。后来 Google 决定让 Kotlin 成为 Android 官方语言，这个机会实在太难得了。
不过，我加入时就对同事说，我大概会离开办公室两年。我的计划是帮助 Kotlin 成为 Android 的一等语言，尽可能推动它取得成功，让自己以后能够放心地依赖这门语言，然后再回到一线，用这些工具真正构建产品。
我喜欢开发工具和库，但不想永远只做工具。我也希望成为这些工具的使用者，并真正享受到前期投入带来的价值。
两年期满时，我原本准备离开，但 Google 恰好批准了另一个我很想做的项目，于是又留下来工作了九个月。最终，我认为自己已经完成了当初的目标，因此决定回到产品开发。
主持人：你不喜欢 Google 的哪些地方？
Jake Wharton：Google 是一家规模非常大的公司。Android 团队相对独立，我在那里遇到的同事也都非常优秀，我至今仍然怀念那段工作。
但我对 Google 这家公司的一些做法存在意见，例如它会通过产品和服务将用户锁定在自己的生态系统中。不过，这些看法主要针对 Google 作为一家公司的运作方式，并不是针对 Android 团队。
主持人：你在 2025 年离开 Cash App 时，科技行业正经历大规模裁员。那时找工作有多难？
Jake Wharton：找工作并不轻松，但市场上并非完全没有机会。我对下一份工作有一些具体要求，因此选择比较谨慎。
我比较幸运，是按照自己的计划主动离职，没有必须立刻找到工作的压力。但现在的就业市场，确实已经不像五年前。那时一名 Android 开发者可能很容易就被公司招走，并获得非常高的薪酬。
现在，求职需要投入更多精力，花费更长时间，也必须想办法证明自己的差异化价值。我非常理解那些被迫进入求职市场的工程师所面对的压力。不过，我不认为整个市场已经彻底崩溃，工作机会依然存在，只是更难找了。
主持人：目前美国资深 Kotlin 工程师的薪酬大概是多少？
Jake Wharton：我通常看到的基本工资是 20 万美元起，此外还可能包括股权，例如每年约 10 万美元的股权，按照四年归属。
当然，低于这个水平的职位也有很多。如今公司会更加谨慎地考虑资金流向，不再像以前那样普遍支付极高的薪酬。
如果希望获得更高回报，就可能需要进入当前最受关注、潜在收益更高的技术领域。这类公司给出的现金和股权可能更多，但风险也更大：股权可能归零，也可能增长十倍。
最终，这取决于个人所处的人生阶段和风险承受能力。年轻时，我愿意承担这种风险；但现在，我更倾向于获得稳定、可预期的现金收入。
主持人：到了 2026 年，掌握 Kotlin 还能给软件工程师带来职业优势吗？
Jake Wharton：我不确定它现在还能算是一项优势。从某种意义上说，这反而体现了 Kotlin 的成功：它已经成为一项默认要求，而不再是一种稀缺、难以找到的能力。
这主要源于 Google 将 Kotlin 确立为 Android 的官方一等语言。如今进入 Android 开发领域，通常就会直接学习 Kotlin，用人单位也默认求职者已经掌握它。Jetpack Compose 同样如此：大约四年前，它可能还是一项相对少见的技能，现在已经逐渐成为默认要求。
如果开发者掌握的不只是常规 Kotlin，而是 Kotlin Multiplatform 等相对进阶的能力，那么它仍然可能构成差异化优势，让你从其他 Kotlin 开发者中脱颖而出。但仅仅“会 Kotlin”，已经很难成为明显的职业加分项，因为它实在太普及了。
为什么拒绝使用 AI 编程？
主持人：你在寻找下一份工作时，公开列出了对未来雇主的九项要求，其中第一条就是“不去 AI 公司、不做以 AI 为基础的产品，也不接受公司强制使用 AI 开发”。为什么这一点对你如此重要？
Jake Wharton：它被放在第一位是有原因的。这可能是我找工作时最看重的一项标准。
我们正处在一个快速变化的时期，不仅软件开发方式在变，许多公司也在强行把 AI——更准确地说是大语言模型——塞进一些原本可能并不需要它的地方。
我不认为过去几年软件的整体质量得到了提高，也不认为这类工具长期来看会改善软件质量。但一些公司高管看到的却是另一幅图景：他们认为 AI 可以让工程师工作得更快，并产出质量更高的代码。我的判断恰恰相反。
除此之外，我对这些工具背后的伦理问题也有很大意见。在我看来，它们建立在大规模使用受版权保护内容的基础上。模型训练忽视了艺术家的版权，也忽视了开源代码的许可证。能够在网上访问一项内容，并不意味着你就拥有重新组合、改写它，甚至逐字输出它的权利。
因此，我不想与这些事情产生关联。只是现在想完全避开 AI 已经越来越困难，所以我把这一要求放在首位。它也直接排除了大约 80%我原本可能加入的公司。
主持人：除了版权和软件质量，你反对的是否还有公司强制工程师使用 AI 的方式？
Jake Wharton：是的。传统上，一项开发工具通常由工程师自下而上推动。
可能是一名工程师喜欢上一门新语言，比如 Kotlin；也可能是一款新 IDE，比如 IntelliJ IDEA；或者是一套新的构建系统。工程师在实际工作中发现它有价值，热情逐渐感染其他人，然后大家再去说服工程管理者批准采用它。
但 AI 工具的推广方向似乎完全相反。为什么要由一家公司的 CEO 告诉工程师，日常工作应该使用什么工具？
公司领导通常不会直接要求你必须使用静态类型语言，也不会决定你应该如何利用类型系统表达业务需求，或者如何处理空值。这些原本都是工程决策。工程师了解业务需求，再选择能够有效完成工作的工具。
如果 Jack Dorsey 当时要求我必须使用 Eclipse，我可能同样会辞职。问题不只在于 AI，而在于公司管理层越过工程判断，强制开发者使用某一种工具。
主持人：为什么管理层强推 AI，会让你联想到科技行业的裁员？
Jake Wharton：如果只是要求使用某种工具，或许还是一个可以单独讨论的问题。但当强制使用 AI 与一轮又一轮裁员同时发生时，整件事看起来就不那么乐观了。
我可以作出个人选择，决定不使用这些工具。我也认为，很多全力投入 AI 的公司是在争抢市场、追逐现金和用户。趁市场火热进入这个领域，从商业角度并不难理解：资金和用户在哪里，公司就会去哪里。
但我比较幸运。经过多年工作，我现在有能力按照自己的价值观选择雇主，并不是所有人都有这样的条件。拒绝 AI 让我失去了大量潜在机会，但这是目前对我而言最重要的标准，所以我愿意接受这个结果。
主持人：你的第二项择业标准是不加入加密货币公司。你反对的是密码学，还是加密货币？
Jake Wharton：密码学是一项有价值的技术，但我不认同加密货币。在大语言模型之前，加密货币是科技行业最受追捧的方向之一，Square 和 Cash App 当时也大举投入其中。
在我看来，加密货币基本上已经变成了一种庞氏骗局，没有创造多少真实价值。这似乎与我对“所有权”的重视相矛盾——我当然支持人们真正拥有自己的资产，不受其他机构控制，但加密货币的问题出在具体实现上。
它最终形成了一个带有掠夺性的系统。真正赚到钱的，往往是利用其他参与者获利的人，或者是在上面搭建业务、不断从客户身上抽取价值的公司。这是我不希望参与的一类行业。
主持人：你希望未来的雇主既使用开源软件，也将自己的项目开源。为什么？
Jake Wharton：我在成长为一名开发者的过程中，几乎一直在接触开源。学习新技术、研究别人如何编写软件时，我首先会去看开源项目。所以对我来说，尝试或构建一项新东西时，默认选择就是把它公开。
后来我加入 Square，我们也成功地将大量技术成果开源。几乎每家公司都建立在他人工作的基础之上。如果一家企业愿意开源自己的成果，或者为其他开源项目作出贡献，这就是一种回馈，也是把自己获得的帮助传递给后来者。
企业不需要从头构建 Linux、Android、SQLite 或者 JVM，因为前人已经完成了这些工作。同样，你今天公开的项目，也可能成为下一家公司或下一代开发者的基础。
主持人：你的另一项要求是公司“小而专注”。为什么你认为做好一件事，比试图服务所有人更重要？
Jake Wharton：我职业生涯中最好的阶段之一，是早期加入 Square 并参与构建 Cash App 的时候。那时公司规模还很小，大家彼此认识，也能围绕一个愿景迅速执行。团队甚至会带着一点天真，相信自己能够做出很多东西。
我加入 Square 时，公司大约有 200 人；后来离开 Cash App 时，公司已经增长到约 1.2 万人。
Google 的规模还要再大一个数量级。公司不断扩大以后，官僚主义随之增加，产品迭代开始放缓，管理层也会越来越急于寻找能够带来新用户和新收入的方向。
相比之下，小团队更容易保持目标的纯粹性，找到一个明确的问题并把它做好。
主持人：大公司除了效率下降，对工程师个人还有什么影响？
Jake Wharton：公司规模越大，工程师的职责往往越狭窄。我听说过一位 Twitter 工程师，长期负责的几乎只是私信界面中的一小部分。当一个人的工作范围被切割得如此细，他就很难再体验产品开发的其他环节。
我喜欢参与不同类型的工作，在一个产品内部不断切换问题。小团队能给工程师更多这样的空间，同时也会带来更多学习机会。
当团队规模较小时，不会有一个 50 人的专门团队替你解决某类问题。你不能只是把需求扔给另一个部门，再等两个月接收结果，而是必须走出舒适区，亲自动手学习和解决问题。对我来说，这种广度和成长机会非常重要。
主持人：经过三个月求职，你在 2026 年 2 月加入 Skylight。这家公司为什么能说服你？
Jake Wharton：Skylight 符合前面提到的许多价值观，更重要的是，我自己就是它的目标用户。
它面向家庭提供硬件产品，而我有家庭，也确实存在相应的使用需求。我一直希望接触更多硬件开发，这份工作正好提供了机会。它与 Android 有关，但又包含许多我以前没有深入做过的事情，例如 AOSP 和真实硬件设备。
Skylight 的应用不通过 Google Play 商店分发，因此我们拥有更大的系统控制权，不必处理 Google Play 体系中的许多问题。这对我而言也是一个有吸引力的新领域。
此外，公司已经获得融资，也有实际收入。我认识 Nova Launcher 的作者 Kevin Barry，他比我早大约半年加入 Skylight。他的选择也增强了我对这家公司的信心。
Skylight 是我求职期间最先接触的公司，后来它反而成了衡量其他机会的标准。市场上并非没有其他优秀公司，但没有一家像它这样完整地满足我的要求。
主持人：Skylight 同样使用大语言模型，这是否违背了你“不加入 AI 公司”的原则？
Jake Wharton：我不认为自己作出了实质性妥协。
Skylight 此前没有做过太多开源工作，但公司愿意尝试，也接受我继续维护已有的开源项目，其中一些项目本身就在产品中使用。
它确实使用了大语言模型，但整个产品并不是围绕 AI 建立的。AI 功能是可选的，用户完全可以不用；它也没有为了追赶潮流，把整个产品改造成聊天机器人。
我认为，公司对 AI 的使用相对克制，也确实用在了合适的位置。我加入以后，也希望继续把自己的这些价值观带进团队。这与加入一家以 AI 为核心、要求所有工程师依赖 AI 开发的公司并不是一回事。
让非技术人员用 AI 编写代码，是进步还是风险？
主持人：Coinbase 裁减 14%的员工，并称“非技术团队现在也能发布生产代码”。你怎么看这种转变？
Jake Wharton：我并不反对降低软件开发的参与门槛。让非工程师更直接地参与产品建设，本身可以是一件好事。
我曾经合作过的一位优秀设计师，用一个周末学习 Android 开发，然后实现了一套非常复杂的动画，直接向代码库提交了 PR。这种跨越岗位边界的贡献非常有价值。AI 如果能帮助更多人以这种方式参与开发，我完全支持。
但它有负责任和不负责任的两种用法。帮助非技术人员表达想法、让他们作出更具体的贡献，是相对负责任的方式；裁掉大量工程师，再把这些工作全部交给大语言模型，则是另一回事。
主持人：一些公司希望用更少的工程师配合 AI 完成原来的工作。你认为这种模式能够持续吗？
Jake Wharton：在我离开 Cash App 以后，据我了解，他们裁掉了 70%的工程师。公司的设想似乎是，一方面让组织变得更加精简，另一方面通过大语言模型，让一名工程师承担过去四个人的工作，甚至让产品人员通过聊天系统直接生成 PR，而不必充分理解代码。
我认为，这种方式在很短的一段时间内可能有效，但长期会导致软件质量下降。至于企业会先遇到质量问题，还是先遇到 AI 成本大幅上涨的问题，我无法确定，但我认为两者都会发生。
现在的大语言模型行业很大程度上仍由资本补贴。典型路径是先用低价吸引用户、抢占市场，让企业形成依赖，再转向按实际价值收费。届时，一些公司的 AI 成本可能增长一个甚至两个数量级。
如果使用大语言模型的成本最终超过原本想要替代的工程师薪酬，那么“用 AI 替代工程师”的经济账也会失效。企业现在大规模裁员并把能力建立在外部模型上，在我看来是一种短视行为。
主持人：你有没有尝试过用 AI Agent 写代码？
Jake Wharton：从来没有。
我有意采取一种比较极端的立场，是希望人们认真思考这些工具背后的问题。科技行业过去很少成立工会，因为薪酬高、待遇好，工程师觉得没有必要争取额外的集体权力。但现在资金减少，大规模裁员出现，很多员工会在毫无准备的情况下被公司抛弃。
在美国，一名员工甚至可能在收到裁员通知之前，就发现公司账号被关闭、邮件不再刷新。工程师越依赖 AI 系统，就越可能把自己的能力和议价权交出去，把自己变成一枚更容易被低成本替代的齿轮。
主持人：你是否认为使用 AI 编程在任何情况下都是错误的？
Jake Wharton：我认为需要从两个维度看待它：一个是伦理问题，另一个是是否负责任地使用。
相对负责任的方式，是把 AI 当作助力，用它增强工程师原本就具备的能力，让工程师更快地表达和实现自己已经理解的东西。
不负责任的方式，则是让 AI 编写超出个人能力范围的代码。如果没有大语言模型，你根本无法完成这项工作，那就意味着你无法真正理解和维护生成的结果，也会对工具形成高度依赖。
假设模型价格上涨 20 倍，公司只能购买原来 4%左右的 Token，你是否会突然失去日常工作的能力？是回到原来的开发方式，还是只在少数枯燥、重复的任务中使用 AI？这就是工程师需要提前思考的问题。
我不认为 AI 会彻底消失，但它应该只是工具箱中的一件工具，而不应成为一个人全部工程能力的基础。
主持人：如果六个月后，AI 写出的代码比你更好，你准备怎么办？
Jake Wharton：我可能会去规模越来越小的公司工作，接受越来越低的收入，同时尽量保留自己的快乐。
我已经不在职业生涯的起点，也不再急于晋升。过去的职业选择给了我一些积累，让我有条件坚持这种强硬立场。我很幸运，因为很多工程师并没有这样的选择空间。
不过，我很难相信 AI 会真正让程序员失去位置。大语言模型建立在人类过去创造的集体成果之上，而软件行业仍然需要有人独立创造新东西。
我记得有研究讨论过，当模型不断使用自己生成的数据继续训练时，可能出现“模型坍塌”。但我当时无法准确回忆研究机构和具体结论。至少在我看来，如果人类停止创造新的高质量内容，模型也很难依靠自己的输出无限提高。
大语言模型的输出归根结底具有统计性，因此始终可能产生错误。就像人们从 Stack Overflow 复制的代码也可能包含漏洞，甚至一些高票答案都有非常隐蔽的问题一样，AI 生成的代码仍然需要有人理解、检查和调试。
所以我不太担心未来完全没有程序员的位置。AI 现在已经强大得令人不安，但这并不等于它能够稳定、无误地承担软件工程的全部工作。
Kotlin 的黄金时代结束了吗？
主持人：Kotlin 最初的一大卖点是减少 Java 样板代码，而 AI 恰好擅长生成这类代码。Kotlin 相对 Java 的核心优势是否已经被 AI 消解？
Jake Wharton：Java 语言架构师 Brian Goetz 反复强调过一点：代码被阅读的次数，大约是它被编写次数的十倍。编写代码本身，从来不是软件工程最困难的部分。
真正困难的工作发生在写代码之前和之后。写之前，你要思考如何解决问题，如何划分系统边界，如何用代码描述复杂的业务；写完之后，还要长期维护。软件会出现 Bug，需求会改变，社会、政策和业务本身也会变化，代码必须随之不断调整。
Kotlin 早期确实很强调“少写代码”：不必手写字段、getter 和 setter，可以使用属性、尾随 Lambda 和更简洁的 DSL。这些特性很容易展示，也能吸引开发者采用 Kotlin，但它们只是进入这门语言的入口，并不是 Kotlin 的全部价值。
一门语言和它的库最终能否生存下来，取决于它能否帮助代码库长期演进。这需要良好的工具、强类型系统和完整的周边生态。AI 可以帮助开发者完成枯燥的任务，比如一次性修改上千个调用点，但它没有消除 Kotlin 在代码维护、类型安全和工具链方面的价值。
主持人：Java 已经加入 Record、密封类等现代特性，与 Kotlin 之间的差距正在缩小。Kotlin 的黄金时代是否已经结束？
Jake Wharton：Java 并没有停滞，更没有认输。它将发布周期缩短到六个月，通过实验性机制让社区提前测试新特性，还对底层基础设施进行了大量改造，使语言更容易演进。
事实上，Java 近年来的一些新特性，设计得可能比 Kotlin 中的对应方案更加完整。Kotlin 必须兼容既有 Java 代码，还要编译成 JVM 能够执行的字节码。Kotlin 刚刚兴起时，需要兼容较老版本的 Java 字节码，因此很多新特性只能建立在原有机制之上。
Java 没有同样的限制。它可以在增加 Record 等语言特性的同时，引入新的字节码，甚至调整虚拟机，让语言、字节码和运行时一起演进。Java Record 因此可以获得更统一的底层实现；Kotlin Data Class 则更多是生成普通 Java 类、常规方法和少量元数据。
如果 Kotlin 希望长期保持竞争力，就必须关注 Java 平台出现的新能力，并找到真正利用这些底层特性的方式。
支持人：既然 Java 在快速追赶，Kotlin 今天还有什么很难被取代的优势？
Jake Wharton：很难被 Java 赶上的一个方面，是 Kotlin 对可空性的处理。
所谓“十亿美元错误”并不是说程序中不应该存在空值。软件始终需要表达“某个值不存在”这种状态。真正的问题是，Java 没有在类型系统中充分描述它，导致开发者可以忽略一个值可能为空的事实，直到运行时才触发空指针异常。
Kotlin 把可空性提升到了类型系统层面。如果一个值可能不存在，开发者必须在类型后面加上问号，并在使用时显式处理。这样一个看似简单的变化，几乎消除了一整类错误。这至今仍是 Kotlin 非常强大的设计。
主持人：Kotlin 主导 Android 开发，Swift 主导 iOS 开发。你认为 Swift 有哪些明显优势？
Jake Wharton：我非常喜欢 Swift。与 Kotlin 相比，Swift 在设计时拥有一张相对干净的白纸。它也要兼容 Objective-C，但不需要像 Kotlin 那样始终受制于既有 JVM 字节码表示，因此语言设计与底层编译方式能够更协调地演进。
第一个明显优势是错误处理。Swift 把错误作为语言中的一等概念：一个函数可能抛出错误，就会被明确标记，调用者也必须处理这种可能性。这与 Kotlin 强制开发者处理可空值有些相似。
Kotlin 则建立在 JVM 异常机制之上。Java 区分受检异常和非受检异常，Kotlin 选择把异常都作为非受检异常处理。结果是，调用一个函数时，你无法从类型和函数签名中清楚看到它可能以哪些方式失败。这会在代码库中埋下“地雷”。
另一个优势是内存表示。Swift 面向原生代码，能够提供真正紧凑的数据结构，更好地利用 CPU 缓存。Kotlin 主要建立在 JVM 对象模型之上，许多数据以类和字段的形式分散在堆内存中，需要频繁进行指针解引用。在一些强调底层性能和内存布局的场景中，Swift 更有优势。
主持人：反过来看，Kotlin 有哪些地方明显优于 Swift？
Jake Wharton：如果只比较语言设计，我甚至认为 Swift 是一门设计得更好的语言。Kotlin 很难找出太多全面领先 Swift 的语言特性。
Kotlin 更大的优势来自语言之外：它的库生态、开源社区、IntelliJ IDEA 提供的开发工具，以及构建系统都更加成熟。尤其是在大型代码库中进行重构时，Kotlin 的体验要好得多。
一门语言即使设计得再出色，如果缺少 IDE、库、静态分析和生产工具，也很难被大规模采用。Kotlin 和 Swift 都是优秀的语言，但 Kotlin 周围这套完整的生态，显著提升了它的实际开发体验。这也是我仍然愿意选择 Kotlin 的重要原因。
主持人：如果比较不同语言的错误和失败建模，你最喜欢哪一门？
Jake Wharton：我喜欢 Rust。Rust 的许多设计非常符合我的思维方式：资源所有权和借用关系应该进入类型系统；谁负责关闭文件描述符，也应该得到明确表达。
这种认同来自多年的开发痛苦。经历过内存泄漏、文件描述符泄漏、空指针异常，以及函数突然抛出未预期异常以后，你自然会思考是否存在更好的解决方式。Rust 把许多过去容易被忽略的问题，直接纳入语言和类型系统。
Rust 的学习难度确实很高，需要跨过一道门槛，才能逐渐形成直觉。我自己也没有达到非常熟练的程度。它未必是最容易使用的语言，但在描述所有权、资源责任和失败模式方面，我认为 Rust 做得最好。
主持人：编写微控制器和嵌入式程序时，你会使用哪门语言？
Jake Wharton：如果是我自己的业余项目，我目前会选择 Rust。公司产品的技术选型需要考虑团队和业务，和个人实验项目并不完全相同。
Rust 的嵌入式生态很有意思。许多库会把硬件能力映射到 Rust 的异步编程模型中。例如，你可以直接等待一次按钮按下事件，不必亲自编写轮询逻辑或配置复杂的中断唤醒机制，一行代码就能表达这种行为。
我的日常工作没有太多机会使用 Rust，而它的设计理念又很吸引我。选择 Rust 既能完成硬件项目，也给了我一个继续学习和体验这门语言的理由。
AI 能够现场生成代码后，还需要开源库吗？
主持人：你写 Kotlin 时，脑子里会不会运行着一个小型的 Rust 借用检查器？
Jake Wharton：我有一份“梦想项目”清单，假如有一天还能领工资，却不必承担具体工作，其中一个项目就是尝试把所有权语义引入 Kotlin。
今年的 KotlinConf 上，已经有研究者提出了非常早期的设想，讨论如何把所有权语义加入 Kotlin，目前甚至还称不上正式的 Kotlin 演进提案。但当你理解 Rust 的所有权和生命周期以后，就会发现很多问题本来可以由语言明确处理。
以 Java 为例，如果别人传给你一个 List，通常需要先做一次防御性复制，因为你不知道对方随后是否还会修改它。Kotlin 通过只读 List 和可变 List 的区分缓解了一部分问题，但还没有真正解决所有权。
如果语言拥有明确的所有权语义，对方把 List 交给你以后，就不能再随意修改；或者只是允许你临时借用，同时明确原持有者仍然拥有修改权。这样可以直接消除一整类共享可变状态导致的错误。
主持人：今天的 Kotlin 开源生态发展到了什么规模？
Jake Wharton：Kotlin 的一大优势，是它能够与 Java 开源生态相互利用。因此，很难把 Java 和 Kotlin 的开源生态完全分开。
我们把 Okio 和 OkHttp 从 Java 重写为 Kotlin 时，曾引起一部分 Java 开发者不满。重写过程中，我们严格保持了二进制兼容性。即便用户通过传递依赖获得了新版库，原来的代码也应该能够继续编译、链接和运行，只是项目中会多出 Kotlin 标准库依赖。
Kotlin 的开源氛围首先来自这门语言自身。Kotlin 完全开源，语言演进过程也公开透明，开发者能够看到每项能力是如何变化的。Kotlin 进入 Android 后，社区很快涌现出大量开源库；当 Kotlin Multiplatform 逐渐成熟以后，又出现了许多满足跨平台开发基础需求的项目。
这与 JetBrains 管理语言的方式有关，也与早期社区形成的文化有关。最早参与一门语言的人会建立一套隐性的行为规范。如果社区从一开始就习惯公开代码、分享工具，这种文化便会延续下去。
Kotlin 可能不是规模最大的开源生态，但毫无疑问属于较大的语言生态之一。
主持人：使用开源依赖会不会把项目置于他人的控制之下？为了安全，是否应该直接 Fork 代码并停止更新？
Jake Wharton：这件事有明显的两面性。建立在他人工作之上能够节省大量时间，但项目也会与依赖库的发展方向绑定。如果维护者作出你不认同的决定，使用者可能会觉得遭到背叛；如果项目更换许可证，企业也可能突然发现，过去免费使用的东西需要付费了。
但根本问题在于，很多人误解了“使用开源软件”的含义。采用一个开源库以后，你应该对它承担一定责任，把它视为自己代码库的一部分。最终，这些代码会与你自己的代码一起交付给用户，用户并不关心哪一部分来自第三方。
公司经常要求工程师必须获得额外批准，才能在工作时间为开源项目贡献代码。我认为这种观念不合理。如果没有这个开源库，工程师就要自己编写和维护同样的功能；既然它已经成为产品的一部分，修复问题、贡献功能和关注项目走向，本就应该属于正常工作。
如果企业持续参与维护，就能提前看到项目的变化，在方向出现分歧时及早调整，甚至与维护者共同找到双方都能接受的方案，而不是直到升级失败时才把责任全部推给开源社区。
主持人：如果大语言模型可以生成那些基础、重复的代码，开发者还需要依赖开源库吗？
Jake Wharton：这种说法低估了共享代码库的长期价值。
开源库的意义不只是替你生成一段眼前可用的代码，而是让许多项目共同受益于持续维护。可能有人今天修复了一个你暂时不会遇到的边缘 Bug，两年后你的业务重构，本来会触发这个问题，但因为你使用的是同一个开源库，它已经被提前解决。
也可能有人把库的性能提高了 15%，所有使用者都会获得这项改进。开源把一次贡献分发到许多不同代码库，而不是让每家公司分别维护一份由 AI 生成、彼此孤立的实现。
因此，AI 能够生成代码，并不意味着共享依赖失去价值。企业应当享受开源带来的效率，同时把依赖当作自己的代码一样关注和维护。
主持人：开源很难直接写进财务报表，企业为什么还要投入人力？
Jake Wharton：把一个内部项目变成真正可用的开源项目，需要额外工作。团队要补充文档和测试，搭建发布基础设施，还要持续处理外部贡献与 Issue。这部分成本并不算巨大，但也不能忽略。
相应地，公司可能获得社区贡献，项目的 Bug 和功能会由更多人共同改进。开源也能展示一家公司的工程文化。开发者看到公开代码后，可以判断团队的技术水平，这可能帮助公司吸引人才。过去 Google 和 Meta 等公司就曾通过开源项目获得大量招聘线索。
对工程师个人而言，公开成果也比口头描述更有满足感。你不必告诉别人“我做了一个很厉害的项目”，而是可以直接把 GitHub 地址交给他，让他使用、修改，甚至在此基础上创造新东西。
不过，公司不应该为了塑造形象而强迫团队开源。哪些项目适合公开，通常能被工程师自然识别。刻意发布一些没有实际价值的项目，社区也能感受到其中的不真诚。
开源同样会带来负担：维护者要应对不友善的 Issue、偏离项目方向的需求、语言沟通障碍，以及大量低质量的 AI 生成 PR。因此，开源并不适合所有工程师，也不应成为强制要求。
Kotlin 的未来
主持人：Kotlin 创始人 Andrey Breslav 在 2020 年离开 JetBrains，一门语言能否脱离创始人继续演进？
Jake Wharton：一门成功的语言必须能够超越它的创始人。一个人投入十年把项目做成功以后，当然有权离开并尝试其他事情。
Kotlin 顺利完成了这次交接，而且整个过程几乎没有成为一场危机。这恰恰证明，它周围已经建立了相对健康的组织体系。
如今，大多数成功的大型编程语言已经不再由一位“仁慈独裁者”单独决定方向，而是由共享的组织结构治理，并在理想情况下与社区共同推进。这样才能减少对某一个人的依赖，让语言长期保持稳定。
主持人：2026 年的 Kotlin 究竟由谁主导？
Jake Wharton：理想答案应该是三者共同参与：JetBrains、Google 和开发者社区。
成立 Kotlin Foundation 的目的之一，就是让这门语言不再完全隶属于 JetBrains，避免任何一家公司能够单独控制它。Google 此前已经经历过采用另一家公司所控制技术、随后陷入长期诉讼的情况，因此在正式采用 Kotlin 时，不可能接受这门语言完全由另一家公司掌控。
社区虽然没有以同样方式直接“加入”基金会，但开发者数量远远超过 JetBrains 和 Google 的语言团队。如果治理机制正常运行，基金会和两家公司就应该持续听取社区意见，再从庞杂的反馈中整理出能够推动语言发展的方向。
原视频链接：