Kotlin is an increasingly popular programming language developed by JetBrains. We sat down with Sebastian Górecki (@sebagorecki) and Robert Kapała (@robertkapala) of GFT Poland to discuss chances for its wider adoption, as well as the potential benefits, such as reduction of risk associated with change – which is especially valuable in software delivery for financial markets.
First of all, could you tell us something about Kotlin as a programming language?
Are there any distinctive features that set Kotlin apart from popular programming languages, e.g. Java?
Sebastian: Well, firstly, Kotlin is more concise when compared to Java, because programs written in it contain, on average, about 40 percent fewer lines of code. It is also more type-safe — it supports non-null types and prevents NullPointerExceptions. There are also some interesting features that cannot be found in Java, namely:
- smart casts,
- separate interfaces for read-only collections and mutable collections,
- extension functions (ability to extend a class with new functionality without having to inherit from the class),
- type inference available not only for local variables,
- data classes,
- …and many more.
One can assume that adoption of a new language is much more complicated than adoption of a new framework. Am I correct?
Robert Kapała: Absolutely. It is quite easy to migrate from Java 6 to Java 8, or from JBoss to Spring Boot (see our story about that on the blog). Changing the language often means that you have to replace the entire ecosystem. Moreover, we have to take into account perspectives of different groups responsible for a particular project. The first group are the developers. Are they ready to accept the new language? Will they be keen to learn it? The second important group are the project owners, quite often being non-technical people. Can they see the benefits of the new approach? Or will they be afraid to be left alone with code written in some language that is known only to a small group of programmers? The third group we must consider are software maintenance team members, and they are not necessarily the same people who had developed the software.
Sebastian: And that is the big difference between Kotlin and other languages that have already been considered as candidates to replace Java. Kotlin is 100 percent compatible with Java! Any code written in Kotlin may be used in Java and vice versa. It should be stressed that you do not need to implement any special calls or workarounds to use Kotlin code in Java. Therefore, it seems natural to mix both languages in projects. We do not have to change the ecosystem and libraries, and we do not need to rewrite the entire project in Kotlin. The risks related to its adoption are therefore lower, and the transition to the new language can be more seamless.
Let’s start with developers. How do they perceive Kotlin?
Sebastian: On the Internet you can find a lot of surveys, and research that demonstrates increasing interest in this new language. In case of developers, it is quite understandable, because they naturally search for solutions that can simplify their work. Kotlin eliminates the need to write the boilerplate code. In some environments, such as Android, it enables you to fully leverage functional programming capabilities.
But the global trend can be different from what is the case for our organization. Therefore, in order to assess the situation at GFT Poland, I prepared a short survey and asked my colleagues to answer its questions. The results are very interesting, because as much as 77 percent of developers are ready to learn the new language!
Are you interested in Kotlin, or do you consider
taking interest in Kotlin in the near future?
Robert: The survey shows that 90 percent of developers have participated in a project that has included non-Java languages. The following chart shows language sets that have been used. I want to point out that the second language has often been used for unit and integration testing, but the production code was written entirely in Java. We can attribute these results to the popular Spock testing framework.
Which JVM languages other than Java
have you used in your projects?
Sebastian: To sum up, it seems that at our company there is a great chance to adopt the new language. You have to remember, however, that at your organization the situation may be different. We recommend conducting such surveys in your environment.
And what about project owners?
Sebastian: At GFT Poland, we work with different customers, so their approaches are quite different. There are projects where introducing a new language will not necessarily introduce benefits from the business point of view. On the other hand, there are also projects that we took over from other teams, and they are already written in Kotlin.
As far as I’m concerned, my project owner has changed his approach over time. One year ago, we were using Kotlin only to write some small tools used for internal purposes. Today, we create Spring Boot services in Kotlin, and they are deployed to the production environment.
How did you manage to convince the project owner? Is there any important reason to consider switching to Kotlin?
Sebastian: As I said, the process took us one year. For our customer, it was the time to become acquainted with the new suggestions, and to place confidence in our team. I think that Kotlin does not offer any extraordinary solutions or features that force us to use it in a project. However, it includes multiple small improvements that — when considered together — result in less code that is also more expressive and readable.
So in most projects it is the developers who are responsible for encouraging the project owners and gradually changing their opinions?
Sebastian: Generally, yes, but that’s not always the case. I know a GFT team that has been given a free hand in their work. The customer said: “As long as the code runs on JVM, you can write in any language you like.” At first, this statement sounded a bit shocking to me. However, it turned out to come from the trust placed by the customer in our team, because earlier we had proven our ability to deliver high quality software on time.
You also cannot say that adopting Kotlin is some kind of developers’ whim. We are always making preparations before taking such decision. One of my colleagues has been preparing for such operation for six months. He has collected the relevant information, and has developed a proof of concept in Kotlin. The goal was to establish for sure that Kotlin would not be a blocker for the project.
And what about the software maintenance team?
Sebastian: In our case, we are the people responsible for the software maintenance. Sadly, I know some cases where Kotlin has not been adopted because of reluctance to transfer such project to the maintenance team.
So, let me ask you perhaps a rather simplistic question… Will Java be replaced by Kotlin in the near future?
Sebastian: Well, I do not want to make any prophecies, because there are a lot of factors that might influence the development of Java and Kotlin in general. While preparing for this article, we had many opportunities to discuss this subject. It turns out you cannot give a definitive answer to this question. Each of us has different thoughts on the matter, which result from our different experiences, from our current projects, and from our expectations related to the new language.
As far as I am concerned, I prefer to write code in Kotlin rather than in Java. In my opinion, even if Kotlin could not make into the “mainstream” set of languages, it is worth learning, because it can extend our perspective and our approach to programming. I may sound odd, but for me learning Kotlin is a good way to become a better Java developer!
But considering your question — well, I think that Kotlin has a good chance to win a large portion of the market. It should become an established alternative in Android projects, or in greenfield projects.
Robert: For me, the return on investment is the most important factor. Learning a new language is always associated with some costs, and no one wants to incur them without a reason. Our reward should consist in an opportunity to use the new skills in practice. In my opinion, Kotlin has a great advantage in that we can use it simultaneously with Java. The entry costs are therefore lower, and it encourages us to try this approach.
Talking about the future — sometimes a single framework (such as Spock or Ruby on Rails), or some charismatic developer (such as DHH or Hadi Hariri), can act as the “game changer.” A lot depends on Java itself, on whether it will keep pace with enhancements introduced in other languages.