JVM语言的兴衰

时不时有一篇文章预测Java语言的消亡。 有趣的是,他们都没有写日期。 但老实说,它们可能都是真实的。 这是每种语言的命运:消失于遗忘-或更确切地说,越来越少地用于新项目。 问题是什么将取代它们?

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

我于2001年下半年开始使用Java进行开发。那时,Java非常酷。 每个年青的开发人员都想开发所谓的新技术:.Net或Java,因为年长的开发人员只能使用Cobol。 我在学校学习过C和C ++,使用Java进行内存管理非常容易。 我对Java感到满意...但并非所有人都满意。

Groovy于2003年问世。我不记得是什么时候知道它的。 我只是忽略了它:那时我不需要脚本语言。 在由许多开发人员组成的团队开发使用寿命长的企业级应用程序的情况下,静态类型比动态类型具有巨大的优势。 必须创建测试来检查类型系统是一个净损失。 我唯一需要创建脚本的时间是作为WebSphere管理员:在Python和TCL之间进行选择。

一年后的2004年, Scala被接受。我不记得何时何地听说它,但是那是很晚了。 但是,与Groovy相反,我决定尝试一下。 主要原因是我长期以来对创建“更好”代码的兴趣-阅读起来更具可读性和可维护性。 Scala是静态类型的,这更多的是我想要的。 我遵循了Scala的Coursera课程《函数编程原理》 它具有三个主要后果:

  • 它质疑我编写Java代码的方式。 例如,为什么在设计类时自动生成getter和setter方法?
  • 我认为Scala使得大多数开发人员(包括我自己)编写不易读的代码变得太容易了
  • 我开始寻找其他替代语言

之后Groovy和斯卡拉来到第二代(3 ,如果算上Java作为第一)JVM语言,其中包括:

随便看了他们一眼,我就确信他们没有太多的吸引力,也不值得花我的时间。

几年前,我决定自学基本的Android,以便能够理解移动开发人员的开发环境。 好家伙! 经过多年的Java EE和Spring应用程序开发,这是一个惊喜-也不是一件令人愉快的事情。 就像过去十年被倒退了一样。 Android API的级别太低了......更不用说在本地测试应用程序了。 快速浏览后,我发现很多地方都提到了Kotlin,最后决定尝试一下。 我立即坠入爱河:有了Kotlin,借助扩展功能,我可以将现有的废话API改进为更好甚至更好的东西。 我进一步研究了该语言,并开始将Kotlin用于服务器端项目。 然后,Spring框架宣布整合Kotlin。 在Google I / O上,Google宣布在Android上支持Kotlin。

这篇文章是关于我个人的经历和由此形成的观点。 如果您更喜欢只阅读您同意的帖子,请随时停止阅读这一点。

除了我自己的经验之外,这些语言的当前状态如何? 在Google趋势上进行了快速搜索

JVM语言的兴衰

有一些有趣的事情要注意:

  • 谷歌已经认识到搜索词 “编程语言”为斯卡拉,Groovy和Kotlin,而不是锡兰和扩展。 对于锡兰,我只能假设是因为锡兰是一个受欢迎的地方。 对于eXtend,恐怕Google搜索量不足。
  • 到目前为止,Scala最受欢迎,其次是Groovy和Kotlin。 我没有关于规模的真正线索。
  • 五月份的Kotlin高峰与Google在Google I / O上的支持声明有关。
  • 对于Scala和Kotlin的大多数搜索都来自中国,Groovy在地理位置方面更为平衡。
  • Scala搜索与术语“ Spark”密切相关,Kotlin搜索与术语“ Android”相关。

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

  • xTend尚未死,因为它从未存在过。 永远不要阅读任何有关它的文章。 也从未听过会议演讲。
  • 2017年,红帽将Ceylon交给了Eclipse Foundation,创建了Eclipse Ceylon 向基金会捐赠软件的私人参与者可能会以不同的方式进行解释。 在这种情况下,尽管围绕此举的谈判令人放心,但这对锡兰的未来并不是一个好兆头。
  • 在2015年,Pivotal停止赞助Groovy,并将其转移到Apache基金会。 尽管我相信Groovy具有足够广泛的支持基础,并且在JVM上具有独特的优势-脚本编写,但这也不是一个好兆头。 这与核心Groovy 提交者的提交频率相关:它们的提交数量急剧减少-甚至停止了一些。
  • 有趣的是,Scala和Kotlin最近都入侵了其他领域,转而使用JavaScript并编译为原生语言。
  • 在Java中, JEP 286是一项建议,旨在通过类型推断来增强语言,Scala和Kotlin已经提供了此功能。 但是,它仅限于局部变量。
  • 有趣的是,人们正在努力通过仅保留一部分语言来缩短Scala编译时间 这就提出了一个问题:如果放弃Scala的强大功能(例如宏),为什么还要保留它呢?

我的预测并不理想,但这里是我的2美分:

  1. Groovy有其自己的细分市场-脚本编写,它使Java,Scala和Kotlin争夺服务器端JVM上的纯应用程序开发空间。
  2. Scala还雕刻了自己的空间。 Scala开发人员通常认为该语言优于Java(或Kotlin),因此不会迁移到另一种语言。 但是,由于Spring和Google的宣布,当语言开发人员对Java感到不满意时,Kotlin可能会取代Scala。
  3. Kotlin赢得了Android之战。 由于Kotlin在游戏中遥遥领先,Scala过去忽略了这一领域,并且将来不会投资。
  4. Kotlin在移动设备上的崛起并不是有意的举动,而是一个令人惊喜的意外惊喜。 但是,JetBrains在注意到趋势后立即将其用作前进的方向。
  5. Kotlin与Java的互操作性是杀手级功能,可以说服管理人员将遗留项目迁移到Kotlin或启动新项目。 就像对Java的不间断的向后兼容性一样。

亲爱的读者,即使您不同意以上内容,我也会非常感兴趣您的意见,甚至(尤其是?)。 请保持礼貌,并在可以证明观点时提供事实。

翻译自: https://blog.frankel.ch/rise-fall-jvm-languages/