共计 2410 个字符，预计需要花费 7 分钟才能阅读完成。
随着 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 的非破坏性向后兼容性一样。
加群获取更多收费材料：3907814
