JVM 语言的兴衰

随着 Kotlin 的崛起，让我们看看对 Java 的不满是如何开始的，JVM 语言是如何形成的——以及哪些语言正在争夺头把交椅。

时不时会有一篇文章预测 Java 语言的消亡。有趣的是，他们都没有写日期。但老实说，它们可能都是真的。这是每种语言的命运：消失在遗忘中——或者更准确地说，在新项目中越来越少地使用。问题是什么将取代它们？

上周在 InfoQ上看到了另一篇这样的文章。至少，这个讲述了一个可能的替代品，Kotlin。它让我思考 JVM 语言的状态和趋势。请注意，趋势与每种语言的技术优点和缺陷无关。

2001 年底，我开始使用 Java 进行开发。当时，Java 非常酷。每个年轻的开发人员都想从事所谓的新技术：.NET 或 Java，因为年长的开发人员被困在 Cobol 上。我在学校学习过 C 和 C++，Java 中的内存管理要容易得多。我对 Java 很满意……但并不是每个人都如此。

Groovy于 2003 年问世。我不记得我是什么时候了解到它的。我只是忽略了它：那时我不需要脚本语言。在由许多开发人员组成的团队开发具有较长生命周期的企业级应用程序的背景下，静态类型相对于动态类型具有巨大优势。进行产品测试以检查类型系统是一种净损失。我唯一一次必须创建脚本的时候是作为 WebSphere 管理员：选择是在 Python 和 TCL 之间。

Scala于一年后的 2004 年问世。我不记得我是何时以及如何听说它的，但那是晚了很多。但是为了反对 Groovy，我决定尝试一下。主要原因是我对创建“更好”的代码的长期兴趣——阅读更具可读性和可维护性。Scala 是静态类型的，这更符合我的要求。我学习了 Coursera 课程中的 Scala 函数式编程原理。它产生了三个主要后果：

它质疑我编写 Java 代码的方式。比如为什么我在设计一个类的时候会自动生成getter和setter？
我认为 Scala 使编写大多数开发人员不可读的代码变得太容易了——包括我自己
我开始寻找其他替代语言

在 Groovy 和 Scala 之后出现了第二代（如果将 Java 算作第一代，则是第三代）JVM 语言，包括：

JetBrains Kotlin
Red Hat Ceylon
和Eclipse 扩展

随便看了一眼之后，我就确信它们没有太大的吸引力，不值得我花时间。

几年前，我决定自学基本的 Android，以便能够了解移动开发人员的开发环境。好家伙！在开发 Java EE 和 Spring 应用程序多年之后，这是一个惊喜——而不是一个愉快的惊喜。仿佛被送回了十年前。Android API 太低级了……更不用说在本地测试应用程序了。快速搜索了一下，发现很多地方都提到了 Kotlin，最后决定试一试。我立刻爱上了：借助 Kotlin，我可以将现有的垃圾 API 改进为更好、甚至更优雅的东西，这要归功于扩展功能。我深入研究了这门语言，并开始将 Kotlin 用于服务器端项目。然后，Spring 框架宣布集成 Kotlin。在 Google I/O 大会上，Google 宣布支持 Android 上的 Kotlin。

有几个有趣的事情需要注意：

Google 已经识别出Scala、Groovy 和 Kotlin 的搜索词，即“编程语言”，但不识别 Ceylon 和 eXtend。对于锡兰，我只能假设这是因为锡兰是一个受欢迎的地方。对于 eXtend，恐怕 Google 搜索还不够。
Scala 是迄今为止最受欢迎的，其次是 Groovy 和 Kotlin。我对规模一无所知。
5 月的 Kotlin 高峰与谷歌在谷歌 I/O 上的支持公告相关。
大多数对 Scala 和 Kotlin 的搜索都来自中国，而 Groovy 在位置方面更加平衡。
Scala 搜索与术语“Spark”密切相关，Kotlin 搜索与术语“Android”相关。

进一步挖掘可能会发现有趣的事实：

xTend 没有死，因为它从来没有活过。永远不要阅读任何关于它的帖子。也从未听过会议演讲。
2017 年，红帽将锡兰交给了 Eclipse 基金会，创建了Eclipse Ceylon。向基金会赠送软件的私人参与者可能会有不同的解释。在这种情况下，尽管围绕这一举动进行了令人放心的谈判，但这对锡兰的未来来说并不是一个好兆头。
2015 年，Pivotal 停止赞助 Groovy，并转移到 Apache 基金会。虽然我相信 Groovy 有足够广泛的支持基础，并且在 JVM 上有一个独特的利基 - 脚本，但这也不是一个好兆头。这与核心 Groovy提交者的提交频率相关：他们的提交数量急剧减少 - 以至于有些人停止了。
有趣的是，Scala 和 Kotlin 最近都侵入了其他领域，转换为 JavaScript 并编译为原生。
在 Java 中，JEP 286是一个通过类型推断来增强语言的提议，Scala 和 Kotlin 已经提供了一个特性。然而，它仅限于局部变量。
有趣的是，通过只保留语言的一个子集来缩短 Scala 编译时间。这就提出了一个问题，如果你放弃了 Scala 的强大功能（比如宏），为什么还要保留它呢？

我不擅长预测

Groovy 有自己的利基——脚本编写，这让 Java、Scala 和 Kotlin 争夺服务器端 JVM 上的纯应用程序开发空间。
斯卡拉也开辟了自己的空间。Scala 开发人员通常认为这种语言优于 Java（或 Kotlin）并且不会迁移到另一种语言。但是，由于 Spring 和 Google 的公告，Kotlin 可能会取代 Scala 作为语言开发人员对 Java 不满意时的去向。
Kotlin 赢得了 Android 之战。鉴于 Kotlin 遥遥领先，Scala 过去忽略了这个领域，未来也不会投资。
Kotlin 在移动设备上的崛起并非有意为之，而是一个美好而意外的惊喜。但是 JetBrains 一注意到这一趋势，便将其用作前进的方向。
Kotlin 与 Java 的互操作性是一个杀手级功能，它可以说服管理人员将遗留项目迁移到 Kotlin 或使用 Kotlin 启动新项目。就像 Java 的非破坏性向后兼容性一样。