With the rise of kotlin, let’s look at how dissatisfaction with Java began, how the JVM language came into being — and which languages are competing for the top spot.
From time to time, an article predicts the demise of the Java language. Interestingly, they didn’t write the date. But to be honest, they may all be true. This is the fate of every language: disappearing into oblivion – or, more accurately, using it less and less in new projects. The question is what will replace them?
I saw another such article on InfoQ last week. At least, this tells about a possible alternative, kotlin. It makes me think about the state and trends of the JVM language. Note that trends are independent of the technical strengths and weaknesses of each language.
At the end of 2001, I began to use Java for development. At that time, java was very cool. Every young developer wants to engage in the so-called new technology: Net or Java, because older developers are trapped on COBOL. I studied C and C + + in school. Memory management in Java is much easier. I’m happy with Java… But not everyone.
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 at that time. In the context of a team of many developers developing enterprise applications with a long life cycle, static types have great advantages over dynamic types. Product testing to check type systems 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 a year later in 2004. I don’t remember when and how I heard of it, but it was much later. But in order to oppose groovy, I decided to give it a try. The main reason is my long-standing 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 scala functional programming in coursera. It has three main consequences:
- It questions the way I write java code. For example, why do I automatically generate getters and setters when designing a class?
- I think Scala makes it too easy to write code that most developers can’t read — including myself
- I started looking for alternative languages
After groovy and Scala, the second generation (if Java is counted as the first generation, it is the third generation) JVM language appears, including:
- JetBrains Kotlin
- Red Hat Ceylon
- And eclipse extensions
After a casual glance, I was convinced that they were not very attractive and were 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 heavens! After years of developing Java EE and spring applications, this is a surprise — not a pleasant surprise. It seems to have been sent back ten years ago. The Android API is too low-level… Not to mention testing applications locally. After a quick search, I found that kotlin was mentioned in many places, and finally decided to give it a try. I immediately fell in love: with kotlin, I can improve the existing garbage API into something better and even more elegant, thanks to the extension function. I delved into the language and started using kotlin for server-side projects. Then, the spring framework announces the integration of kotlin. At the Google I / O conference, Google announced its support for kotlin on Android.
There are several interesting things to note:
- Google has recognized Scala, groovy and kotlin’s 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 xtend, I’m afraid Google search is not enough.
- Scala is by far the most popular, followed by groovy and kotlin. I know nothing about scale.
- The kotlin peak in May was related to Google’s support announcement on Google I / O.
- Most of the searches for Scala and kotlin come from China, and groovy is more balanced in location.
- Scala search is closely related to the term “spark”, and kotlin search is related to the term “Android”.
Further excavation may reveal interesting facts:
- Xtend didn’t die because it never lived. Never read any posts about it. I’ve never heard of a conference speech.
- In 2017, red hat handed Ceylon over to the eclipse foundation to create eclipse Ceylon. Private participants who give software to the foundation may have different explanations. In this case, despite the reassuring negotiations around this move, it does not bode well for the future of Ceylon.
- In 2015, pivot stopped sponsoring groovy and transferred it to the Apache foundation. Although I believe that groovy has a broad enough support base and has a unique niche script on the JVM, this does not bode well. This is related to the submission frequency of core groovy submitters: their number of submissions has decreased dramatically – so that some people stopped.
- In Java, JEP 286 is a proposal to enhance the language through type inference, and scala and kotlin have provided a feature. However, it is limited to local variables.
- Interestingly, Scala compilation time is reduced by retaining only a subset of the language. This raises the question, if you give up Scala’s powerful functions (such as macros), why keep it?
I’m 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 her own space. Scala developers generally believe that this language is superior to Java (or kotlin) and will not migrate to another language. However, due to the announcements of spring and Google, kotlin may replace Scala as the destination when language developers are dissatisfied with Java.
- Kotlin won the Android war. Given that kotlin is far ahead, Scala has ignored this area in the past and will not invest in the future.
- Kotlin’s rise on mobile devices is not intentional, but a beautiful and unexpected surprise. But as soon as JetBrains noticed this trend, it used it as a way forward.
- Kotlin’s interoperability with Java is a killer feature that can convince managers to migrate legacy projects to kotlin or start new projects using kotlin. Just like Java’s non-destructive backward compatibility.
Add group to get more free information: 3907814