摘要：早在 2002 年，Rod Johnson 就提出了对 Java 企业级开发的批判性看法，并推出了一种更加简洁、灵活的替代方案——Spring 框架。20 多年后，这位从事编程 30 多年的元老级码农又燃起了对 Kotlin 的兴趣。那么，是什么让他弃 Jav

作者｜Sebastian

编译｜傅宇琪

策划｜冬梅

早在 2002 年，Rod Johnson 就提出了对 Java 企业级开发的批判性看法，并推出了一种更加简洁、灵活的替代方案——Spring 框架。20 多年后，这位从事编程 30 多年的元老级码农又燃起了对 Kotlin 的兴趣。那么，是什么让他弃 Java 转向 Spring？他又是如何看待 Kotlin 的未来的呢？

最近，Rod Johnson 在播客节目中，与主持人 Sebastian 和 Márton 详细回忆了 Spring 诞生故事，并分享了他最近重返 JVM 的历程，以及作为 Kotlin 新手的种种乐趣。基于该播客视频，InfoQ 进行了部分增删。

核心观点如下：

开源需要激发人们的兴奋感，这不仅仅是财务激励的问题，更是关于构建组织、创建企业并产生影响力的问题。

Kotlin 更友好、更易读、写起来更有趣，它是一个更现代的语言。

Kotlin 具备了 Python 让我喜欢的所有优点，却没有那些我不喜欢的缺点。

Kotlin 语言本身似乎也没有给人一种“通过做最复杂的事情来彰显聪明才智”的感觉，这种专注于清晰和可读性的氛围是非常健康的。

Spring 的诞生

Márton：Spring 是如何诞生的？

Rod：我认为，许多成功的软件往往都源自于开发者曾经亲身经历过痛苦。因此，Spring 之所以能够成功，其中一个原因是，最初参与 Spring 开发的许多开发者，很多是从企业应用开发领域走出来的。

Spring 的诞生可以说有些特殊。许多核心理念，比如后来被称为“依赖注入”，我是在 1999 到 2000 年期间在伦敦工作时提出的。随后，我写了一本书，进一步阐述了这些理念，并认为用代码来展示这些思想将是一个有用的示例。之后，读了这本书的人找到了我，询问这些代码的许可问题，能否在实际应用中使用，同时也问是否能帮忙改进这些代码。因此，Spring 的开源项目实际上就是从这本书开始的。

Sebastian：从一个框架的设想，到将它转化为一个实际的、能够持续维护的框架，并且准备好供他人使用，这个过程还是相当具有挑战性的。

Rod：我认为从一本书开始的确比我当时意识到的更具优势，因为这意味着每个人都在同一页面上，没有关于架构风格的争议。实际上，今天 Spring 一个非常显著的特点就是它的一致性。如果你了解 Spring 的某一部分，你就知道其他部分是如何运作的。

团队成员的质量也起到了重要作用。比如，Juergen Hoeller 就是一位令人惊叹的开发者，第一位贡献大量代码的人竟然是这样一位如今享有盛誉的开发者，这无疑也有一定的运气成分。社区也起到了非常重要的作用，那时开源社区还没有什么行为规范，但我们自己就是正直的人，不容忍任何不良行为，真心想帮助他人，尊重他人，尽力回答问题。我认为，这也使得团队随着发展，始终保持着专业和良好的行为，社区成员也十分感激这一点。

将 Spring 发展成为一个主流框架，要求我们做出艰苦的努力和一些好运。我认为自己对商业的兴趣也在其中扮演了非常重要的角色。早在 2004 年，我就清楚地表达了，Spring 必须有一个可行的商业模式，因为这个项目太雄心勃勃、太复杂，单靠志愿开发者是无法支撑下去的。

2000 年代初到中期，Java 开源市场上有两个重要的玩家：JBoss 和 Spring。我认为 Boss 并不具创新性，如果你有能力使用 WebLogic，你会选择 WebLogic，而不是 JBoss，因为 WebLogic 本身就更好。JBoss 的重要性在于它让你不需要购买昂贵的应用服务器，但它本质上是开源市场的商品化。Spring 则不同，它提供了从 BAA、Oracle、Sun 或 IBM 那里无法获得的东西，而要做到这一点，必须有一个稳固的经济模型。

Sebastian：首先，关于 Spring 框架的一致性，虽然它有很多动态的部分，但如果支撑它的思维模型是一致的，你就可以在不同的部分之间做出合理的假设，这点总是让人感到非常愉快，这也是我喜欢 Kotlin 的一部分原因。我一直形容它就像是有很多不同的零件，它们像乐高积木一样拼接在一起，你能很清楚地看到这些部分如何组合在一起，背后有一种相对一致的哲学。您能否进一步扩展一下关于在开源背景下，如何实现可持续发展呢？

Rod：Spring 不仅规模巨大，而且与众多其他工具有集成，因此我们很早就遇到了这样一个问题：IBM 在每个 WebSphere 的重大版本发布时，总喜欢玩一个游戏，叫作“把事务管理器放到一个你找不到的地方”。此外，还存在一些不同产品中的 bug 和性能问题，这些问题需要迅速解决，但无法依赖于志愿者开源社区来解决。在 2000 年代每一个 WebSphere 版本发布时，Juergen 都确保 Spring 与该版本完美兼容。但即使 Jurgen 再优秀，也无法保证他会把这个问题列为待办事项的首位，尤其是他不全职从事 Spring 工作的话。

说实话，我对开源的现状有些沮丧。曾经有一段时间，开源正在确立自己作为一个商业类别，我认为 JBoss 在这一过程中发挥了非常重要的作用，因为它展示了你可以拥有一种不同的模式，使公司和个人能够更容易地获得技术。大概直到 2010 年代初期，似乎开源收购变得越来越大，且这种现象从商业角度看具有很强的潜力。然而，不幸的是，向云计算的转移在这方面造成了不少问题。

我认为，开源如果能够维持可持续发展，对几乎所有人都有好处。我相信开源开发者如果不能从中创造财富，是不利的。例如，如果我唯一能期望的就是找到一份薪水不错的工作，我可能就没有太多动力了。开源需要激发人们的兴奋感，这不仅仅是财务激励的问题，更是关于构建组织、创建企业并产生影响力的问题。比如，Elasticsearch 的 Shay Banon，他并不是为了成为一名员工而工作，即使他得到了很好的认可和薪酬，他的动力来自于创造某种东西，做出改变，并且在这一过程中拥有更多的话语权。

Márton：开源项目通常需要非常有激情的个人付出巨大的努力来推动，最终才能实现可持续发展，同时必须拥有某种盈利模式。而 Spring 的故事也很有意思，它来自一群实际开发应用的人员，而不是那些单纯为了框架而创造框架的人，这与 Kotlin 的诞生非常相似。Kotlin 也不是一个学术性项目，而是在 JetBrains 的开发者希望用它来支持他们的实际产品时诞生的。那么，你是如何开始使用 Kotlin 的呢？

使用 Kotlin 的种种乐趣

Rod：我实际上有很长一段时间远离了 Java 和 Spring。大概在 2009 年 SpringSource 被收购的时候，接下来的两三年里，我几乎没有写什么代码。后来，我真正开始接触 Scala，之后由于参与的多个项目，我做了很多 TypeScript 和 Python 的工作。大约在去年此时，我对 Python 感到厌倦，决定将开发语言换成 Java 和 Spring。那时我当然知道 Kotlin 已经推出，而由于我已经熟悉 Scala，学习 Kotlin 似乎是顺理成章的选择。

但是，我还是有意识地花时间将自己更新到现代 Java 的水平，因为我最后一次写 Java 代码，可能还是 Java 7。我认为，在深入了解其他技术之前，我应该先彻底熟悉 Java。事实上，Java 的确有很多改进。然而，最终我还是对 Java 中的流操作感到厌烦，坦白说真是有些尴尬。我记得我是在散步时决定，“好吧，试试 Kotlin 吧，总比这强。”我觉得 Kotlin 的学习曲线非常平缓，大约两个月之后，我几乎完全不想再写 Java 代码了。所以，现在我写的所有代码都是 Kotlin。尽管如此，我从来不会成为 Java 的“黑粉”，事实上，我认为现代 Java 实际上比人们给的评价要好得多。

然而，如果有机会使用 Kotlin，我真的觉得很难拒绝它，因为 Kotlin 更友好、更易读、写起来更有趣，它是一个更现代的语言。当然，我在个人项目中也对 Scala 有过同样的感受，但即使在我最热衷 Scala 的时期，我也能清楚地看到，作为经理，如果我要管理大规模项目，我可能不希望团队使用 Scala，因为我们都知道，使用 Scala 的大型项目常常会带来问题。但 Kotlin 就不会有这种感觉，Kotlin 中的所有特性，我认为都很实用，它来源于实践者，而非学术界。每个特性似乎都是为了某个实际目的而存在，而不是为了迎合学术上的时尚。

另外，你可以在 Kotlin 里看到 Scala 的很多经验和元素。这是一个非常宝贵的经验，因为它让我们看到什么是可能的，然后我们想，或许我们可以用更实用的方式实现这些功能。

Márton：有一场非常精彩的演讲，标题大概是《站在巨人的肩膀上（Shoulders of giants）》，演讲者讲述了 Kotlin 如何建立在 Scala 这样的技术基础上，以及从中学到的经验。他还提到，Kotlin 在构建过程中吸取了包括 Python 在内的其他语言的特性，作为其某些功能的基础。

Rod：使用 Kotlin 有两件事让我感到惊讶。第一件事是我竟然这么喜欢它。第二件事是，我的 Kotlin 代码看起来竟然很像 Python。虽然我写了很多 Python 代码，但总体上我并不喜欢 Python 作为语言。然而，Kotlin 具备了 Python 让我喜欢的所有优点，却没有那些我不喜欢的缺点。例如，它具备了 Python 的清晰性和可读性，但它有更好的类型系统，并且让我能够使用 Spring，能够在 JVM 上运行。

Márton：我认为回顾 Kotlin 最初的定位和专注于 JVM 的背景，真的很有意义。而且，回想一下每个人第一次接触 Kotlin 的时刻，我觉得我们所有人都有类似的体验。我写的 Kotlin 代码越多，我就越为之欣喜。我相信，很多听众也经历了类似的体验，尤其是在他们第一次开始使用 Kotlin 时。

Rod：Kotlin 的学习真的几乎没有痛点，没有太多让你一开始就容易犯错的地方。其次，如果你已经熟悉 JVM，当然可能是从 Java 入手，但如果你至少了解 Python 或 Scala，我认为学习 Kotlin 会非常容易。更不用说，现在我们有了一个绝佳的学习资源——LLMs。基本上，ChatGPT 帮助我以比其他方式快得多的速度学习 Python，它也在学习 Kotlin 时帮助了我不少。

我发现 LLMs 在写 Kotlin 代码时表现得非常出色。尽管我同时使用 Python、Java 和 Kotlin，但 Kotlin 的代码完成质量远高于 Python 和 Java。虽然这听起来有点意外，因为 Python 和 Java 是最广泛使用的两种语言，但考虑到它们的最佳实践已经发生了很多变化，这一现象是可以理解的。

现在，写 Python 应该使用类型提示等更新特性，尤其是 Python 3.10 及以上版本，而 Java 也应使用 records 等新特性。相比之下，Kotlin 并没有这些问题，吸引了许多早期采用者，许多高质量的代码由这些开发者编写。

最初我对 Kotlin 的代码质量感到意外，但随着时间推移，我发现 Python 和 Java 的代码质量差异更加明显。对于 Kotlin，我几乎从未收到糟糕的代码建议，而 Python 和 Java 中，尽管我调整提示语，仍常得到我现在绝不会写的代码。

Sebatian：我们也认为，Kotlin 语言内部的高度一致性可能有助于 LLMs 的表现。在 JetBrains，我们特别在 AI 助手方面做了一些工作，IDE 中的模型已经针对 Kotlin 代码进行了微调。我认为 Kotlin 在这些年里保持了一致的发展路线。如果回顾三到五年前的 Kotlin 代码，尽管有些差异，但许多核心原则依然适用。我很好奇，虽然我自己没有尝试过，但想了解一下你用的 LLMs，是否已经开始建议你使用 Kotlin 中一些“现代”的特性，比如函数式接口、上下文接收器，我很好奇 LLMs 是否已经能够充分利用 Kotlin 的所有语言特性。

Rod：总体来说，LLMs 提供的建议质量似乎相当不错。我不太记得它是否建议使用函数式接口，但总体上，它的建议看起来符合 Kotlin 的习惯用法。

Sebastian：这是我个人觉得非常有趣的一点，尤其是提到 Kotlin 中的作用域函数（scope functions）。像 let、apply、run 这些函数，确实需要一点时间来适应。当我看到一段看起来比较像 Java 的代码时，里面可能只是做了几个空值检查，或者已经使用了 Kotlin 的智能类型转换特性，但它们仍然只是简单地堆叠空值检查。这时，我向 LLM 询问，“有没有更好的方法来写这些？”结果它把这段代码转换成了使用 Elvis 操作符和早期返回的写法，实际上充分利用了 Kotlin 语言能够根据返回路径推断空值性的特性。这个转换让我感到非常震惊，我必须承认，这种体验真的让我大开眼界。

Rod：我完全同意，我认为大部分的建议确实是符合 Kotlin 的习惯用法。如果我在讨论代码时使用 LLM，我通常会选择 Claude，因为我认为 Claude 在处理代码时的表现要好很多，尤其是在持续的代码推理方面。

我认为 Kotlin 的一个真正优点就是，你可以在没有太大痛苦的情况下开始使用它。有些语言你根本不能轻松上手，比如 C 或 C++。事实上，我认为 Java 之所以如此成功，其中一个原因就是它是一门你可以毫不费力地开始使用的语言。编写的代码不太可能引发那些不明显、严重的问题。因此，我绝对认为，对于转向 Kotlin 的开发者，他们应该放轻松。如果一开始他们写的代码没有使用很多 Java 做不到的特性，那也没关系。毕竟，这不是他们一年后写的代码，他们可能会回来进行修改，但那也不会导致什么严重问题。所以，我认为 Kotlin 的学习过程是没有压力的。

关于代码的可读性，这其实是很主观的，但我总体来说觉得，Kotlin 代码并不难读。而与此相对，Scala 中有许多人有自己的写法和习惯，而且不幸的是，Scala 社区曾经被那些功能编程的狂热者主导，他们坚信一切必须是纯粹的。相反，我觉得 Kotlin 不仅是一个可读性很高的语言，而且它似乎也不容易吸引那种过于追求“纯粹性”的人群。

Sebatian：在 Kotlin 的世界里，人们通常都非常务实。你刚刚说自己还没有完全接受 Kotlin 中的扩展函数。这个话题值得深入讨论，因为我们在与许多人交流，或者在社交媒体上看到，很多人都把扩展函数作为他们爱上 Kotlin 的第一大特性。所以，我很想知道你对扩展函数的看法是什么？能和我们分享一下你不喜欢它的原因吗？

Rod：我理解为什么扩展函数在框架中非常有价值。Kotlin 的一个优势是，它不像 Scala 社区那样在 JVM 上重新发明每一个轮子，而是拥抱了现有的技术。我完全理解，能够轻松编写对象映射、注册 Kotlin 模块等功能，确实使得许多现有的 Java 工具变得更好用。

不过，我自己在代码中并没有广泛使用扩展函数。虽然在使用像 Jackson 这样的库时，我实际上受益于扩展函数，但我对它是否真的必要仍持怀疑态度。对我来说，扩展函数有点像“魔法”，而且坦白说，我从 C++ 转到 Java 的一个原因就是，C++ 中你必须到处寻找类定义，而 Java 则更具指导性，类定义明确、可预测。所以，尽管 Kotlin 中的扩展函数需要导入，我其实更喜欢这一点，它限制了扩展函数的作用范围。

老实说，我并没有过多使用扩展函数。实际上，有几次是 LLM 建议我使用扩展函数，我可能保留了一两个，但通常我对它持怀疑态度。我认为它是一个很好的集成功能，帮助更好地利用 Java 库，但对我个人而言，我并不觉得自己有强烈的需求去使用它。

Sebatian：我觉得 Kotlin 的一个魅力就在于，你可以根据自己的需要选择使用不同的语言特性。从 Kotlin 诞生以来，这种灵活性一直存在。我想说的是，Kotlin 经历了典型的“炒作周期”。当一个新的语言特性推出，或者团队开始采用 Kotlin 并学习到新的特性时，往往会出现一种“全力以赴”的现象——他们可能会过度使用这些新特性，突然之间，所有的东西都变成了扩展函数，或者所有的东西都变成了顶级函数。然后，随着时间的推移，人们会逐渐明白这些特性带来的维护负担，或者它们对代码可读性产生的影响，最终大家会找到一个适合自己的平衡点。

Márton：当团队第一次采用 Kotlin 时，确实会出现这样的情况：他们一开始写得像 Java 一样，过度使用特性，然后不得不进行调整，避免使用过多层次的嵌套作用域函数，以及各种他们试图塞进代码中的“魔法”特性。

Rod：其实，我得承认，我并没有仔细查看过 Kotlin 的语言发展路线图，也没太关注它是如何发展到今天的。我只是使用当前版本，老实说，我喜欢这种不需要去关注路线图的感觉。目前，我可能在 Kotlin 和 TypeScript 之间非常纠结，都是我最喜欢的语言。如果让我选择，我可能会选择 Java 加 Spring，而不是 TypeScript 加 Node.js。所以，如果有两种语言在质量上不相上下，我的选择还是偏向于 Kotlin。

不过，确实有些特性我还挺怀念的，比如我很怀念联合类型和类型代数。虽然我知道有时候这些特性可能会用得过度，但像联合类型和部分类型这样的特性真的非常有用。唯一一个我觉得有点问题的地方是 Kotlin 中的对象字面量语法，其他的 Kotlin 语法我都觉得很漂亮、简洁。

Márton：Kotlin 也在逐步演进，一些最初没有的语言特性现在已经变得习以为常。这种进化非常有趣，既有坚实的基础，又在不断前进。每次更新都一步一步地推出新特性，这些小变化累积起来推动了 Kotlin 的进化。现在我们已经超越了 2.0，迎来了新的编译器，未来语言的演进速度可能会加快，因为新编译器的推出将使我们能够在不需要实现的情况下推进更多新特性。

Rod：从语言版本的角度来看，Kotlin 显然比 Scala 要轻松得多。Scala 的一个显著问题就是版本不断变化，导致很多东西被打破，这一直是使用 Scala 的一个大问题，直到现在依然如此。

另外，我一直认为，大家对编程语言的关注过于集中，而生态系统实际上是至关重要的。如果你看看 Kotlin，它与 Java 世界的集成非常出色，这与当时你在使用 Scala 时的体验截然不同。Scala 当然也能将 Java 代码写得更优雅，但是你也能遇到另一种情况，有人用 Scala 写的代码可能只有他们自己能理解，而他们还为此感到骄傲。但如果你在一个需要和 Java 库进行交互的环境中工作，Scala 的互操作性就非常痛苦。你会发现，你花了大量时间在解决这些互操作性的问题上。

相比之下，Kotlin 的互操作性几乎为零，这真的非常了不起。我必须承认，虽然我多年来偶尔有接触 Kotlin，知道它与 Java 的集成非常好，但我还是花了大约两三周的时间在 Kotlin 中心想，“好像应该快出现什么问题了，这一切太顺利了，迟早会碰到什么麻烦的集成问题。”但事实是，我并没有遇到任何麻烦。

我其实并没有深入研究 Kotlin 底层是如何实现的，但我可以想象，它从 Scala 的经验中受益匪浅。比如，Kotlin 如何提供非常好的集合库，而不会给开发者带来痛苦。这是一个很大的优势，因为 Scala 在这方面曾经经历过一些问题，而 Kotlin 显然通过这些经验做得更加顺畅。

Sebastian：我觉得你提到的批评是非常有道理的，尤其是你说在与 TypeScript 合作时，有一些东西在类型系统上缺失。我个人也同意这个看法。实际上，我们的语言设计团队也在关注这些问题。我们希望确保 Kotlin 能够与语言中的所有操作符等进行良好的集成。所以，我希望我们能够找到比 Java 中当前的受检异常更符合人体工程学的解决方案，这也是我最大的期望。

Rod：比较密封层次结构和联合类型时，我的经验是，密封层次结构是一个相对边际的特性，虽然它有一些价值，但联合类型的价值要大得多。使用密封层次结构时，你必须在开始时就知道太多信息，而联合类型则允许你在消费数据时定义自己的规则，这实际上是它的一大优势。使用密封层次结构时，所有的规则必须事先定义好，而联合类型则更灵活，允许你根据需要动态地定义处理方式。

Sebastian：你觉得 Kotlin 作为语言和 Spring 作为框架的结合如何？你觉得它们之间的契合度怎么样？

Rod：Kotlin 和 Spring 的结合现在几乎是完美的。多年来，Spring 一直倾向于使用构造函数注入，这与 Kotlin 的写法非常契合。我现在几乎不再使用 is，而是大量使用不可变对象。Kotlin 编译器的 Spring 插件非常重要，因为有时类默认需要是 open 的。刚开始时我不喜欢这种方式，更倾向于显式地写 open，但后来我意识到这种做法其实是个好主意。

现在的 Spring 非常简洁，没有冗余的部分。XML 已经消失了 10 到 15 年，通常只需要定义一次。而即便是在使用现代 Java 时，尤其是构造函数等情况，常常需要多次声明。因此，我认为，如果 Spring 开发者想真正体验 Spring 的强大，应该尝试使用 Kotlin 而非 Java。你会发现，很多表面上的棱角其实并不是 Spring 的问题，而是 Java 本身的问题。Java 21 及以上版本的 Spring 已经相当不错，尽管它常常受到不公平的批评。如果有选择使用 Kotlin，我认为 Kotlin 更合适，它更现代，代码没有重复，很多东西只需写一次。

对于我使用的库，Kotlin 的扩展函数在 Jackson 中的应用非常好，使得操作更加顺畅。一旦注册了 Kotlin 模块，Jackson 就能顺利工作。不过，唯一让我觉得不太优雅的是 JPA。其实，我从不认为对象关系映射是坏事，反而认为它是一种强大的技术。如果你懂得如何使用，JPA 和 Hibernate 的实现已经比其他替代方案好很多。虽然 Kotlin 在使用 JPA 和 Hibernate 时的表现比 Java 好，但我觉得它与 Kotlin 的自然风格不完全契合，主要是因为 JPA 基于可变性设计，而 Kotlin 则更倾向于不可变性。这并不是 Kotlin 的问题，而是处理一个本身就需要可变性的 API。

总的来说，尽管 JPA 与 Kotlin 的结合没有我在其他领域的使用体验那么愉快，但它依然能正常工作，并且与 Spring 数据仓库的集成非常好。我现在不再使用 Optional，而是直接使用可空类型，并且它工作得非常好。

Sebastian：作为有一定 Spring 经验的开发者，你的学习路径可能会不同于普通开发者。你的学习过程是从写类似 Java 的代码开始，然后逐步转向 Kotlin，还是依赖于一些示例来加深理解的呢？

Rod：我有一个使用现代 Java 构建的 Spring 应用程序，并且采用了当前所有的最佳实践。Spring 文档对于 Kotlin 的支持非常好，其中包含了许多示例，明确说明你可以选择使用 Kotlin 或 Java。因此，Kotlin 始终是一个完全受支持的选择。除了我提到的默认 open 问题之外，Kotlin 的学习曲线几乎不存在，这个问题同样适用于一些其他框架，如 JPA 等。

此外，由于我已经熟悉 Spring，学习 Kotlin 时并没有遇到任何惊讶。对于这些技术的集成，我没有任何问题。正如我之前提到的，在现代 Spring 中，你已经开始使用不可变性等功能。例如，在使用 Spring 的配置属性源时，数据类会被自动注入。如果你想在 Kotlin 中使用某个语言特性，它通常能与 Spring 的相关功能很好地兼容。

未来展望

Márton：你曾在 2013 年 Scala Days 上发表过一场广为引用的演讲，讨论了 Scala 在 2018 年的发展愿景，讲述了 Scala 需要在五年内达到的目标，以便能够广泛采用并实现稳定。现在，Kotlin 也正接近这种状态，距离它最初的稳定发布已经接近 10 年。你是否已经有了一些关于 Kotlin 未来五年的想法？你期望这个语言在那时会有哪些发展或变化？

Rod：我必须承认我并没有仔细思考过这个问题。2013 年关于 Scala 的愿景，大部分是关于解决我认为阻碍 Scala adoption 的痛点，比如二进制不兼容性等问题。这些痛点直接影响了人们能够从 Scala 中受益的程度。因此，当时的愿景是围绕着需要解决这些问题，以减少痛苦。

对于 Kotlin 来说，情况会很不一样。我认为，首先 Kotlin 应该继续拥抱 Java 生态系统，尤其是在 JVM 上运行时。JVM 非常重要，Kotlin 在这方面的优势是巨大的。你可以使用 Spring、Jackson、JPA 等技术，而且它们都能很好地兼容并且运行得很顺利。此外，我认为，虽然可能在兼容性上有一些挑战，但基本的类型代数会非常有用。比如，联合类型和部分类型这两个特性是非常有用的，它们可能是我最希望看到的两个改进方向。

但我也认为，Kotlin 不必像 TypeScript 那样做过多复杂的类型代数。有些 TypeScript 代码我觉得过于复杂，完全不必要。Kotlin 在这些基础特性的完善上做得很好，应该继续保持和改进。

另外，关于对象字面量，我认为可以考虑简化其语法。对我来说，这感觉是语言中最不直观的部分。每次写对象字面量时，我总是需要记住它是不是写对了。对于 Kotlin 中的其他部分，我几乎不需要这样反复确认，所以这是我认为可以改进的地方。

最后，模式匹配也是一个值得关注的领域。实际上，Java 在模式匹配方面走在前面，甚至可能在这一方面进一步领先。我认为，Kotlin 在这个领域的提升会是一个很不错的改进方向。

Márton：继续拥抱 Java 生态系统是非常重要的。未来 Kotlin 在这些方面的提升一定会带来更好的体验。

Rod：Scala 的社区曾有很多来自学术界的人，他们总是试图把每件事做得非常复杂，追求“聪明”的做法，而这并不是 Kotlin 社区的特点。Kotlin 社区并没有这个问题，大家更多关注的是实用性和可理解性，这一点非常好，我也希望这种文化能够持续下去。Kotlin 语言本身似乎也没有给人一种“通过做最复杂的事情来彰显聪明才智”的感觉，这种专注于清晰和可读性的氛围是非常健康的。

Sebastian：你是否愿意分享一下你正在做的项目是什么？

Rod：基本上，我在探索知识图谱和 RAG 的相关工作。传统的向量搜索存在严重的限制，而尝试从结构化和非结构化内容中提取知识图谱，可能为 RAG 提供一种更优的替代方案。这对我来说非常有趣，因为首先，我认为可解释性在现实世界的 AI 应用中至关重要。仅仅说“在那 1750 亿个参数中有某种权重组合得出了这个答案”并不足够，微调并不是解决 LLM 在实际使用中面临的许多问题的答案。另外，我一直是图数据库和知识图谱的忠实支持者，这在我看来是一个非常重要的领域。

另外，我也想说的是，人们不必非得使用 Python 来进行生成。实际上，我从 Python 转到 Java 和 Spring AI 时，虽然当时我对 Python 非常熟悉，但转到 Java 后，我发现自己在需要的工作中反而更加高效。而现在，当我使用 Kotlin 时，我的生产力又得到了提升。所以，虽然对于那些想从事生成领域的开发者来说，Python 是必需的（任何认真对待自己职业发展的开发者都必须能够至少流利阅读并能写 Python），但如果他们在 JVM 上构建应用，且所在的组织也主要使用 JVM，那么转向 Python 并不总是最佳选择。Spring AI 的进展非常好，你可以继续使用你熟悉的技术，集成现有的库和后端服务，而生成工作也能顺利进行。

参考链接：

https://www.youtube.com/watch?v=Rx3XZoqbi78

来源：InfoQ