The rise and fall of the JVM language

With the rise of Kotlin, let's take a look at how the dissatisfaction with Java started, how the JVM language was formed - and which languages are vying for the top spot.

From time to time there will be an article predicting the demise of the Java language. Interestingly, none of them wrote the date. But honestly, they may all be true. This is the fate of every language: disappearing into oblivion-or more accurately, being used less and less in new projects. The question is what will replace them?

Saw another such article on InfoQ last week. At least, this one speaks of a possible alternative, Kotlin. It makes me think about the state and trends of the JVM language. Please note that trends have nothing to do with the technical advantages and disadvantages of each language.

At the end of 2001, I started to develop in Java. At the time, Java was very cool. Every young developer wants to work on the so-called new technology: .NET or Java, because older developers are stuck on Cobol. I have studied C and C++ in school, and memory management in Java is much easier. I'm very satisfied with Java...but not everyone is like that.

Groovy came out in 2003. I don't remember when I learned about it. I just ignored it: I didn't need a scripting language then. In the context of a team of many developers developing enterprise-level applications with a long life cycle, static typing has a huge advantage over dynamic typing. Performing product testing to check the type system is a net loss. The only time I had to create a script was as a WebSphere administrator: the choice was between Python and TCL.

Scala came out in 2004 a year later. I don't remember when and how I heard about it, but it was a lot late. But in order to oppose Groovy, I decided to give it a try. The main reason is my long-term interest in creating "better" code-reading is more readable and maintainable. Scala is statically typed, which is more in line with my requirements. I learned the principles of functional programming in Scala in the Coursera course. It has three main consequences:

• It questions the way I write Java code. For example, why do I automatically generate getters and setters when I design a class?
• I think Scala makes it too easy to write code that is not readable by most developers-myself included
• I started looking for other alternative languages

After Groovy and Scala appeared the second generation (if Java is counted as the first generation, then the third generation) JVM languages, including:

• JetBrains Kotlin
• Red Hat Ceylon
• And Eclipse extension

After taking a casual glance, I was convinced that they were not very attractive and not worth my time.

A few years ago, I decided to teach myself basic Android so that I could understand the development environment of mobile developers. Good guys! After years of developing Java EE and Spring applications, this is a surprise - not a pleasant surprise. As if sent back ten years ago. The Android API is too low-level...not to mention testing the application locally. After a quick search, I found that Kotlin was mentioned in many places, and finally decided to give it a try. I fell in love immediately: With Kotlin, I can improve the existing junk API into something better and even more elegant, thanks to extensions. I delved into the language and started using Kotlin for server-side projects. Then, the Spring framework announced the integration of Kotlin. At the Google I/O conference, Google announced support for Kotlin on Android.

There are a few interesting things to note:

• Google has recognized Scala, Groovy and Kotlin search terms, namely "programming language", but does not recognize Ceylon and eXtend. For Ceylon, I can only assume that this is because Ceylon is a popular place. For eXtend, I am afraid that Google search is not enough.
• Scala is by far the most popular, followed by Groovy and Kotlin. I don't know anything about scale.
• The Kotlin peak in May is related to Google's support announcement on Google I/O.
• Most searches for Scala and Kotlin are from China, and Groovy is more balanced in terms of location.
• Scala search is closely related to the term "Spark", and Kotlin search is related to the term "Android".

Digging further may reveal interesting facts:

• xTend did not die because it never lived. Never read any posts about it. Never heard of conference speeches.
• In 2017, Red Hat handed Ceylon to the Eclipse Foundation and created Eclipse Ceylon. Private participants who donate software to the foundation may have different explanations. In this case, despite the reassuring negotiations surrounding this move, it does not bode well for Ceylon’s future.
• In 2015, Pivotal stopped sponsoring Groovy and moved to the Apache Foundation. Although I believe that Groovy has a broad enough support base and a unique niche on the JVM-scripting, this is not a good sign. This is related to the frequency of submissions by core Groovy committers: their number of commits has dropped drastically-so much so that some people stopped.
• Interestingly, Scala and Kotlin have both invaded other areas recently, converted to JavaScript and compiled to native.
• In Java, JEP 286 is a proposal to enhance the language through type inference, and Scala and Kotlin already provide a feature. However, it is limited to local variables.
• It is interesting to shorten Scala compilation time by keeping only a subset of the language. This raises the question, if you give up the power of Scala (such as macros), why keep it?

I am not good at forecasting

• Groovy has its own niche-scripting, which allows Java, Scala, and Kotlin to compete for pure application development space on the server-side JVM.
• Scala also opened up his own space. Scala developers generally consider this language to be superior to Java (or Kotlin) and will not migrate to another language. However, due to Spring and Google announcements, Kotlin may replace Scala as the destination of language developers when they are dissatisfied with Java.
• Kotlin has won the battle for Android. Given that Kotlin is far ahead, Scala has ignored this area in the past and will not invest in it in the future.
• The rise of Kotlin on mobile devices was not intentional, but a wonderful and unexpected surprise. But as soon as JetBrains noticed this trend, it used it as a way forward.
• The interoperability of Kotlin and Java is a killer feature that can convince managers to migrate legacy projects to Kotlin or use Kotlin to start new projects. Just like Java's non-destructive backward compatibility.

Add group for more free information: 3907814