Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why I Started Learning Kotlin

DZone's Guide to

Why I Started Learning Kotlin

This interview explores why one dev jumped from Java to Kotlin, what benefits the JVM language brings, and why you should add it to your toolbox.

· Java Zone
Free Resource

Just released, a free O’Reilly book on Reactive Microsystems: The Evolution of Microservices at Scale. Brought to you in partnership with Lightbend.

If you walk into ObjectStyle's dev office in Minsk, you will easily spot Ruslan's desk by the abundance of Kotlin stickers on his machine. Ruslan has been with ObjectStyle since 2016. When he's not busy turning China-grown gourmet tea into exceptional code, he heads the Belarus Kotlin User Group and talks about the language at various conferences.

We sat down with Ruslan to discuss why he took up Kotlin, why he finds the language fascinating, and how he sees Kotlin's future.

Q: When was the first time that you heard of Kotlin?

I came across Kotlin in May of 2015 while looking at different Java alternatives.

And the reason I was doing that was because Java's evolutionary pace had been slowing down. It's an old language, which comes with baggage. Oracle is forced to make newer versions of Java backward-compatible, or else they risk angering many programmers whose legacy code depends on it. This leads to some really old issues persisting, to disproportional amounts of boilerplate code, and to other problems.

Even before stumbling onto Kotlin, I gave Scala and Groovy a shot, hoping that they'd be better than Java. They are both fine languages, but they each have their own drawbacks. With Groovy, it’s not clear what the code does on some occasions; I don’t feel "safe" using it. Whereas Scala seems to have a steep learning curve. In addition, I wasn’t happy with the way both languages work in IDE.

Eventually, the research led me to Kotlin. I was immediately impressed with how simple the syntax was. Besides, I saw many annoying Java problems solved in Kotlin. For example, the null pointer exception — also known as the billion-dollar mistake - is technically impossible in Kotlin because the language uses the type system, which checks for null references during compilation, as opposed to Java doing the same in runtime. And this is not the only Java puzzler that Kotlin did away with — there are quite a few. If you want the full list, there is a talk by Svetlana Isakova of JetBrains on the topic somewhere on the Internet.

I was immediately impressed with how simple the syntax was. Besides, I saw many annoying Java problems solved in Kotlin.

Q: OK, maybe this is a naive question, but if Kotlin is so great, why isn’t everyone switching over to it yet?

First off, developers are a skeptical bunch; we are hard sells. To tell you the truth, my first reaction to Kotlin was "Oh no, not another Java alternative."  And many think this way. Normally, a programmer has little incentive to try out some random new solution, unless they are really unhappy with the one at hand.

I've also heard people say "I don’t like Kotlin" when they haven’t even tried writing code in it. Turns out, the person has a problem with some other JetBrains product and assumes that Kotlin is no good. And some people are just happy with Scala or Groovy, so they don't want to dive into yet another language.

Oftentimes, it's a matter of which language is used organization- or team-wide. Let's say I love writing in Kotlin, but if the rest of the company and the project uses Java - then what can I do?

Still, Kotlin has been enjoying enthusiastic adoption like no other language. Once you try it, it's hard to go back to Java or use anything else. Stephen O'Grady of RedMonk recently said that programmers adore Kotlin "in a fashion that is rare," and I tend to agree.

Still, Kotlin has been enjoying enthusiastic adoption like no other language. Once you try it, it’s hard to go back to Java or use anything else.

Q: Are there known brands using Kotlin?

Viber's ride-sharing startup Juno is written in Kotlin. I find this ironic because they kind of used "a better Java" to build "a better Uber."

Another big name on Kotlin's portfolio is Corda, an open-source distributed ledger platform that's supported by the world's major banks. It's been built exclusively with Kotlin.

Speaking of the world-known brands, Kotlin is now a first-class Android development language with official support from Google. Netflix and Atlassian's Trello both use Kotlin to develop their apps.

There are also some lesser-known use cases from people who try to use Kotlin in data science and game development.

That said, Kotlin is already being adopted by large enterprises (most likely because of its 100% interoperability with Java). There may be a tipping point sometime in the future when the number of Kotlin users begins to increase exponentially.

I find this ironic, because they kind of used "a better Java" to build "a better Uber."

Q: So, what are your thoughts on the future of Kotlin?

Right now, JetBrains strives to make Kotlin the choice for multi-platform development. They stressed this point during the introduction of Kotlin/Native, which is currently in technology preview.

The idea is to allow developers to write a platform-agnostic core for an app and then run it on any supported platform (be it Kotlin/JVM, Kotlin/JS, or the upcoming Kotlin/Native) with little modification.

Surely, there are other multi-platform development solutions already out there such as Xamarin, Cordova, ReactNative, or Electron. But actually, apps built with Xamarin or with Cordova tend to look the same across platforms and don't adapt. At the same time, the upcoming Kotlin/Native module will allow developers to leverage the platform's native design elements in the application interface and provide a truly native experience.

Also, Google announcing official support for Kotlin on Android is big news. Now I'm really looking forward to seeing Kotlin tools in Android Studio 3.0 out of the box.

Part of the work I do for kotlin.link includes monitoring the language's popularity, and I noticed a huge spike in Kotlin searches and trials immediately after the Android partnership was announced. Taking into account that 88% of the smartphone market is owned by Android, the impact of this news is hard to overestimate. So, thanks, Google.

Google announcing official support for Kotlin on Android is big news. Now I'm really looking forward to seeing Kotlin tools in Android Studio 3.0 out of the box.

Q: In one of your talks, you mentioned that Kotlin helps programmers write asynchronous apps easier. Could you expand on that a bit?

Sure. Pretty much like Go has Goroutines, Kotlin has Coroutines. They first came out in Kotlin 1.1 in the beginning of March as an experimental feature, and are expected to go stable in Kotlin 1.2.

Anyone who has written asynchronous code the "bad" old way knows how difficult it is to make it work. Coroutines make it much easier, so that writing async apps becomes no different from writing synchronous ones.

Once JetBrains releases a stable version of this functionality, we'll be able to say that Kotlin now offers the best tools for writing async applications.

Once JetBrains releases a stable version of this functionality, we'll be able to say that Kotlin now offers the best tools for writing async applications.

Q: I see. I guess it’s time to wrap up. How would you sum up Kotlin’s strengths and benefits?

If I were to take a page from Kotlin's book (that is, from their website), I could mention the four key benefits that are often associated with Kotlin.

First of all, Kotlin is pragmatic. It's aimed at solving practical problems. It does not strive to satisfy all possible academic principles. That is, achieving a goal is the #1 KPI.

Second, Kotlin is a safe language, in a sense that you always know what the code does at any given time. Like I said, Java is riddled with so-called "puzzlers," code behavior paradoxes that fall into the category of "it works - why? It doesn't work – why?" And the fact that Kotlin has gotten rid of many of these puzzlers makes it a safe choice.

Third, Kotlin has excellent interoperability with Java. You can use Kotlin in a Java project as if it were Java, and vice versa. The majority of Java-specific tools and libraries will work out of the box with Kotlin. Arguably, this is the language's biggest strength. Also, although you can use Java from Kotlin without a problem, sometimes you’d want to get a more idiomatic API. Kotlin allows you to do that with ease, as you can see in the example of the bootique-kotlin library that I've written. 

You can use Kotlin in a Java project as if it were Java, and vise versa. The majority of Java-specific tools and libraries will work out of the box with Kotlin. Arguably, this is the language’s biggest strength.

Fourth, yet another benefit is clarity. Being able to quickly look through a body of code and understand what it does is what every developer wants. We read code as much as we write it (if not more). In some instances, what is achieved with 7 lines of code in Java, can be done with just 1 line in Kotlin. So, Kotlin's conciseness and expressiveness is a big asset.

In the end, I have faith in this language, because it's backed by a commercially successful company that just happens to make one of the world’s most-used IDEs. Which means you don’t have to worry about tooling support at all… Plus, it's crystal clear why JetBrains created this language, what problems it solves and what their strategic vision for the future is.

So, if you ask me, that’s why I started learning Kotlin.

Follow Ruslan Ibragimov on Twitter or check out his profile on LinkedIn.

Strategies and techniques for building scalable and resilient microservices to refactor a monolithic application step-by-step, a free O'Reilly book. Brought to you in partnership with Lightbend.

Topics:
java ,kotlin ,jvm languages ,asynchronous

Published at DZone with permission of Alesia Krush, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}