Shulou(Shulou.com)06/03 Report--

This article mainly explains "what is the reason why Java server-side developers do not use Kotlin". The explanation in this article is simple and clear and easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the reason why Java server-side developers do not use Kotlin?"

It has been almost five years since I wrote my first Kotlin book after fifteen years of using Java.

Our team did not follow the typical Java manual: we used Utterlyidle instead of Spring and adopted Totallylazy's functional programming approach. We are loyal supporters of IntelliJ and try to make the most of the tools it provides for Java.

At that time, our vision had gone beyond Java. There are teams that are interested in Scala, and we have written some services with it. But the complexity, pain, and slow build time of working with the Java code base makes the language unattractive to most of us.

When Google announced in 2017 that Kotlin would become the official language for Android development, another team close to us evaluated the language in their server-side development. In the end, most of us gave it a try.

I was shocked by the impact of Kotlin on our code base. It feels more productive and secure, and the tools are not as mature as Java, but they are enough to make it worthwhile for us to adopt.

It is also interesting to extricate yourself from a language that feels stale and lengthy and to discover which coding styles are well suited to the features of Kotlin. Excellent interoperability with Java means that we can rely incrementally on existing ecosystems and transition systems without major disruption to the completion of the work.

Soon, I became interested in Kotlin, co-founded http4k, a functional toolkit for Kotlin HTTP applications, and held a "real-world Kotlin development seminar" to help other teams make the same transformation.

In the end, I have moved to another position, but I am lucky to see the server-side application of Kotlin in various other projects. I have also experienced first-hand some of the reasons why the team is strongly reluctant to adopt Kotlin.

Strangely, resistance does not always come from the pros and cons of the actual language. So why isn't the Java server-side community adopting Kotlin more?

Some of the reasons that my colleagues and I encountered are as follows:

We have no time to learn a new language

This is the common variant of "busy chopping firewood, busy sharpening axe" in software projects. This is often a sign of deeper problems, such as rising technical debt and productivity problems in general.

Healthy software projects always require a considerable amount of learning. A competent Java developer can master the basics of Kotlin in a few hours and be reasonably productive in a few days.

When they write simpler code and deal with fewer problems, it is a worthwhile investment to increase productivity because of the new language.

Every version of Java is constantly improving.

It's true: Java is getting better. And the speed of release is getting faster and faster. On the other hand, it still lags far behind Kotlin in dealing with simple things like emptiness.

Perhaps the Java community has become accustomed to the pace of development of the language. Nevertheless, Kotlin provides a way to take advantage of many (and more) of these features in their projects.

As Java developers, we are very happy

This resistance is the trickiest. If a programmer ties his professional identity to a single programming language, there is nothing he can do about it.

On the one hand, I can understand if Java developers don't want to gamble on their careers and jump into the uncharted territory of a new language. Or they want to be a long-term expert, which is fair.

On the other hand, I haven't seen Java developers "lag" because they use Kotlin. On the contrary, it shows that they are always looking for the best tool for their job, which is a positive trait, at least for the people I help recruit.

Kotlin is a highly hyped language with an uncertain future.

This is a common objection we saw around 2017. In that year, Google accepted Kotlin as a first-class language developed by Android, reassuring us that big players were interested in the long-term development of the language.

This may not be common today, as popular frameworks such as Spring and Micronaut seem to have embraced new languages.

It is hoped that this language will be well-known enough for more server-side people to try.

I'm using Eclipse, but I don't want to switch to IntelliJ

To be fair, the Kotlin experience in Eclipse may not be consistent with JetBrains IDEA.

This is understandable because JetBrains's business model includes selling its developer tools. And that is unlikely to change any time soon.

Their only hope is that Kotlin reaches a critical mass, which justifies further investment in Eclipse support. Until then, the best development experience for Kotlin developers will remain on JetBrains products.

My point is that IntelliJ is already a better Java IDE, so it's worth a try.

Kotlin developers are too expensive to get

It's hard to assess this: on the payroll website, it can be concluded that Kotlin's salary is generally slightly higher.

If we only want to think about server-side developers, it's hard to compare. Generally speaking, it is the highest-paid area in the Java field, and there is not enough data on Kotlin to compare.

Rumor has it that we have seen in practice that experienced Java developers are often the first to adopt Kotlin, which may give people the impression that Kotlin developers are expensive.

In terms of recruitment, we haven't seen the problem of attracting Kotlin developers. We make it clear that we need to use the new language for our work and accept that developers learn the new language at work.

This seems to reassure Java developers and attract those who are keen to learn new things, which is also a potentially appropriate indicator.

Kotlin is too complicated.

One of the reasons why Kotlin has become a compelling alternative to languages such as Scala is that it strikes a proper balance between developer ease of use and advanced features, making it possible for it to be operable with Java and adopted by popular frameworks.

In practice, this objection is often related to the skills, styles, and practices of individual teams.

Beginners tend to start writing Kotlin in the same way as Java. As they become more familiar with the language, they are likely to push some features, such as extensions and inline functions, too far, making the code base difficult for beginners to understand.

Until the team is fully qualified for the new language, we strongly advocate using Boring Kotlin (TM) for as long as possible. In the end, most teams will find a balance between picking cool language features and making the code available to the entire team.

It is confusing to use two languages in one code base

People who have not tried Kotlin in actual projects are generally worried.

In practice, as long as the team agrees and notices that new Kotlin code needs to coexist with Java in the first place, using two languages in one project does not cause obvious pain.

A helpful rule is: "if the change involves two languages, first convert the old code to Kotlin."

In this way, the team can avoid drastic rewriting and gradually move places that need to add new value.

It doesn't matter if some of the code is still in Java. It's probably because the code still works and there's no urgent need for refactoring.

We feel more comfortable with Java.

In practice, it may be that a specific context does not require a new language. Everything is fine; the team gets things done at an acceptable speed and has a good grasp of the problems that Kotlin will help solve.

However, in our experience, this is the exception rather than the rule. More often, this resistance stems from a general lack of time or interest in learning, rather than a lack of areas for improvement.

It's hard to appreciate the benefits of Kotlin before trying a real project, and introducing a new language, even as an experiment, can cause a lot of anxiety.

In these cases, we recommend "on-the-job learning" (in the form of coding dojos, Brownbag meetings, etc.) to create a safe environment in which such experiments can take place.

This approach allows teams to evaluate their use of Java and whether it is worth investing in Kotlin.

I don't know what advantages Kotlin will bring.

Sometimes Java developers are unaware of the limitations of the language or are too used to them. At other times, they will reject any choice of language that makes them question the current choice.

Without going into details, we can say that the simplicity and security of Kotlin are its main advantages. However, some people will say that they don't think there is a problem with Java's verbosity, and that the code written is already safe.

It's easy to deny Kotlin before trying, and when faced with a choice, a few people will continue to look for reasons not to try.

Thank you for reading, the above is "what is the reason why Java server-side developers do not use Kotlin". After the study of this article, I believe you have a deeper understanding of the reason why Java server-side developers do not use Kotlin, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.