最好的时代可能已经过去。如果 Kotlin 到 2025 年还没有重大进展，其受欢迎程度就会下降并达到临界点。
在 Infobip 担任软件工程师的 10 多年时间里，我的大部分时间（如果不是最多的话）都用来维护代码。更多的时候，是维护别人的代码。
我有幸（或者说是倒霉，取决于你怎么看）目睹了各种技术的爆炸和内爆——再也没有在新的项目中使用过。
其中一次发生在 2014 年。在Infobip创建和维护一项产品的团队分崩离析，由我的团队接手并维护它。它拥有所有最新的花里胡哨–node.js、Cassandra、MongoDB、Redis、MSSQL、Groovy、Grails、ELK，等等。选择这些技术的人是谁、如何选择以及为什么选择并不重要。唯一重要的是，复杂性预算太疯狂了。
复杂性扼杀了项目
我原来所在的团队花了一个多月的时间才在本地设置好一切，以便能够启动项目并进行测试。很快，我被调到了另一个团队，在那里，我的任务是建立一个概念验证，一个 MVP 产品，它的功能与我们要维护的产品相同，但使用的技术最少。
我们就像在 Infobip 的大部分工作一样开发这个产品。使用简单枯燥的 Java 和 MSSQL……仅此而已。那是在 2015 年，而这项服务在 2023 年的今天依然存在。最初项目的复杂性扼杀了它。更糟糕的是，它还扼杀了本应维护它的团队。
这个故事的寓意是–你需要格外小心你的复杂性预算。这不仅关系到你要维护的服务或库的数量，还关系到你需要维护的各种技术的数量，以及一项技术的未来前景。
当 Groovy 还是 Groovy 时
2013 年，JVM 上最热门的语言之一不是 Java，而是 Groovy。它有 lambdas、动态结构、命名参数构造函数、流行的 Grails 框架等等。但就在 2014 年，似乎没人能预料到，Java 8 发布了一个新的热门功能–lambdas。
lambdas 消除了当时对 Java 最重要的负面评价之一–大量匿名内部类在代码中传递行为。或者，就像人们常说的那样–Java 没有 lambdas。不久之后，大约在 2015/2016 年间，Groovy 出现了明显的衰落。如今，Groovy 的使用率已大幅下降，甚至没有人会想到在创建新服务时使用它。
但是，JVM 生态系统的创新并没有随着 Groovy 的衰落而衰落，恰恰相反。下一个炙手可热的新事物是 Scala！
还有人记得 Scala 吗？
我记得！我甚至完成了 Coursera 课程 “Scala 中的函数式编程原理”，该课程的作者是 Martin Odersky。说实话，Scala 比 Groovy 的功能更让我着迷。我在 Java 中最缺乏的就是模式匹配。用简单的类 lambda 表达式浏览复杂的数据结构时，不（滥用）访问者模式。
有一些 Infobip 服务是用 Scala 编写的，但一直没有起色。大约在 2017 年，Scala 语言的一位主要维护者离职后，Scala 开始走下坡路。
Kotlin 的到来
下一个 “杀死 Java “的竞争者是 Kotlin。它慢慢兴起，但对我来说，它真正开始兴起是在2017年左右，首先是我们的People产品诞生时–其后台是用Kotlin编写的，然后是我们的默认Maven父版本增强了对Kotlin的支持。第一个重要事件是 Infobip 首次大规模部署使用 Kotlin，而第二个事件则标志着大规模采用的开始。
Kotlin 的优点
Java 代码互操作性
虽然并不完美，但 Kotlin 的 Java 代码互操作性比其前辈更好。这很可能是因为它是在 Groovy 和 Scala 之后出现的，可以从它们的经验和缺陷中吸取教训。
此外，它也不需要任何专门的构建工具（如 Scala 的 sbt），而且有插件并与 IntelliJ 集成。它是由最受欢迎的 Java IDE 创建者 JetBrains 创建的，这是它的一大优点，但它也有一个缺点，我将在后面的缺点列表中与大家分享。
例程Coroutines
这一点在 Infobip 软件生态系统中非常重要。它为异步任务的扩展问题提供了一种语法上的廉价解决方案。尤其是与 RxJava、Reactor、CompletableFutures 等相比。
在 Java 21 问世之前，Java 在这一功能上还没有竞争者，但随着java 21 和虚拟线程的发布，它拥有了这一功能。明年将是决定 Java 排名的关键一年。
如果虚拟线程表现出色，并降低了转用 Kotlin 来实现例程的价值，那么这将标志着 Kotlin 衰落的开始。尤其是如果 JetBrains 拿不出能带来巨大价值的新热门功能的话。
数据结构和模式匹配
在records (16) 和模式匹配（21）之前，Lombok 是 Java 中唯一的选择。
我比一般的 Java 开发人员更不喜欢 Lombok，尤其是因为它打破了 Java 注释处理的第一条规则–注释处理器不应该修改 Java 编译器生成的 .class。
不过，通过records ，我认为这是一个比 Kotlin 提供的更好的长期解决方案–尤其是考虑到本次 Java 语言更新中多少解释了一些计划（如需完整的上下文，建议观看整个视频）。
Java 21 模式匹配具有类型模式和穷举性，因此这是 Kotlin 不再具备的一个优势。
Null 处理
在 Java 中，Null 一直是个隐患。有了备受争议的Optional类型后，情况略有改善。这也是为什么我建议大家在任何地方都只使用封装类型，而不要使用基元类型，除非他们能通过 JMH 测试证明基元类型能带来足够的性能优势。
Kotlin 有所谓的 Elvis 运算符支持，这在现代语言设计中的Null处理选择中相当流行。这总比什么都没有要好，但它与语言类型系统的交互可能会显得非常不符合人机工程学，而且很不稳定。比起在代码中使用”.s.”，我更喜欢使用一般的 monad 方法，即使用广泛确立的 map 和flat map 约定。
Java 中Optional 的最大缺点不是它的语法开销，而是围绕它是否应该全部使用的争议。最初，它几乎是专门为 Java 8 Streams 而创建的，JDK 维护者的 “其他人都不应该使用它 “的口号确实很有杀伤力。最近，甲骨文公司越来越多的人公开表示，可以而且应该在所有地方使用 Optional，而不是冒着 NPE 的风险，这里就是一个最好的例子。
我的看法是，他们不希望大量采用和实现将 Optional<?> 类型作为三种可能值集（null、Optional.of 和 Optional.empty）的存储空间，这样整个 Valhalla 值对象项目就可以更轻松地将 Optional 变为不允许 null 的内联类型（如前所述，这将破坏所有使用 Optional 的代码）。这样做总比可能破坏野生代码和坚持认为他们没有遵守 Optional 的 Javadoc 要容易得多。
其他特性
Kotlin 中的其他特性，如语言语法和方法扩展，并不值得一提。为语言带来特性而带来特性可能是相当有害的。最大的 “红旗 “例子来自前面提到的另一种语言–Scala，它和 C++ 一样，提供了在类型上重载操作符的选项。当你不能再安全地假设某个操作符会做你期望它做的事情时，这样的事情会让代码变得非常难以维护。
扩展方法就是最好的例子。在一家公司中，每个团队都是由初级、中级和高级人员组成的。这可能会导致很多糟糕的代码，给新手带来很多陷阱。关于这一点，还有一件事–如果你希望任何人通过入门仪式就能维护一段代码，那你的行为就不像一个软件工程师。恰恰相反，你违背了软件工程的道德规范！代码必须是可维护的，这才是首要任务。
Kotlin 的缺点
Java 代码互操作性
你会问，第一个优点怎么会是缺点呢？官方博文清楚地描绘了这幅图景。引述如下
接下来的事情很简单：我们希望 Kotlin 能够推动 IntelliJ IDEA 的销售。
现在你可以想象，为什么 IntelliJ IDEA 在这么多年后还能将 Java 转换为 Kotlin，而不能将 Kotlin 转换为 Java。这是厂商锁定并攫取更大利润的惯用手法–这种做法在 2023 年又开始流行起来。但我想说的是
Kotlin 生态系统
与 Java 相比，Kotlin 生态系统严重不足。FAANG 对 Java 有一流的支持和承诺，比如为 JDK 提供多年支持承诺。
劳动力
时至今日，Kotlin 开发人员仍明显少于 Java 开发人员。
这对使用 Kotlin 的公司意味着什么？更昂贵的劳动力和寻找项目人员的障碍。他们可以选择等待市场上出现合适的人选，也可以开始让自己的 Java 开发人员入职 Kotlin。这两种选择都需要花钱。
缺乏进展
与 Java 相比（例如两年前的records 、模式匹配和今年发布的 VT），Kotlin 在提供能为我们（Infobip）带来价值的重要功能方面一直停滞不前。对我来说，这是 Kotlin 最令人担忧的地方，而目前提到的所有其他地方都相形见绌。
扮演魔鬼代言人
事实上，我们需要 Kotlin。为什么需要？为了帮助我们研究、创新和挑战现状。
如果 Kotlin 继续停滞不前，而又没有新的竞争者推出新的热门功能来提高我们的交付效率，这将是一个问题。对于一家有一半甚至更多基础架构是用 Java 编写、仅在 JVM 中运行的公司来说，跳转到 Kotlin 等替代品要比 Rust 或 Go 便宜得多。我们需要选择，不应该把所有鸡蛋都放在一个篮子里。
严峻的未来
作为这篇博文的结尾，这就是标题的内容。在 Infobip，从 2017 年到今天，一直是 Kotlin 的黄金时代。能否继续下去，完全取决于 JetBrains 及其对 Kotlin 的创新能力。关键时刻要到2025年。
为什么是 2025 年？到那时，我们将看到更多 Java 功能（如 Valhalla 和 Panama 项目），而没有 Kotlin 替代品。如果到那时 Kotlin 还不采取重大举措，其受欢迎程度就会下降并达到临界点。在 YouTube、Hacker News 或 Reddit 上的开发者社区中，你已经可以看到向这个方向发展的情绪，但现在还不是临界点。
你的反应是：