Kotlin: Ready for Production

Download Slides

Kotlin, a language developed by JetBrains for nearly 5 years, is very close to its first release. However, did you know that it has been being used in production for over a few years already? Both inside and outside of JetBrains, there are people deploying Kotlin applications for the Android platform, web applications, and just about any other type of application.

Why are people using it instead of Java or some of the other languages out there? Primarily because it provides significant benefits in terms of concision, readability, and safety. All that, yet without some of the drawbacks that adopting a new language might have, such as a steep learning curve or interoperability issues with existing code. In this talk from GOTO Copenhagen 2016, Hadi will cover some aspects of Kotlin that can help you in your daily development, focusing on solving issues and highlighting language features.

---

Introduction (0:00)

Kotlin was started in 2010 by JetBrains, where I work. JetBrains has been around for 16 years, and we make different types of tools (mostly IDEs and Teamware tools, but also some .NET stuff). All of the IDEs and Teamware tools are built in Java. We make IDEs for pretty much every language that’s out there, but most of the code is in Java. However, we just created a C# IDE, running on the JVM, that is written in Kotlin.

We were looking for a new language because we wanted something that was more concise, expressive, interoperable, and overall pragmatic. Being more concise than Java isn’t setting the bar high, because Java is as overloaded as it gets. At the time, there were basically two languages that were potential candidates: one of them was Scala and the other one was Ceylon.

We didn’t choose Scala because performance was an issue (this was 2010). Tooling was also a very big issue. To give you some perspective, if there are about 35 people on the entire Git team, there are 11 people on the Scala plugin.

Ceylon fit very nicely, but at some point, our interests somewhat diverged. That’s when we decided to start Kotlin.

We wanted to focus on interoperability and tools. We make tools, so we wanted to make sure that the language that we created was one that we would want to use for ourselves. Our idea was to stop writing Java, but at the same time we didn’t throw a decade of code in the bin. We’re not the startup that can just throw everything away and then write the next best thing.

What we needed was a language that could interoperate with everything in a smooth way. From day one, Kotlin was developed under Apache 2 OSS, and it’s been on Github ever since. The current state was released in February 2016 because we wanted to have a long period of dog food. It’s very hard to create a language, and there was a long period of testing, trialing, and making sure we wouldn’t mess things up. There were quite a few changes along the way, and decisions that were made initially around the language were later revoked or changed.

Current State (3:32)

Right now, there are around 22 developers at JetBrains working on Kotlin. There are over 100 committers at JetBrains, and it’s being used in 10 products. Our goal wasn’t to create a language onto which we could bootstrap some consulting or training; our goal was to create a language that we could use for ourselves.

Our commitment to this language and its future is in the tools. The tools, our bread and butter, are now being written in Kotlin. IntelliJ has parts written in Kotlin, and some of our newer tools are entirely written in Kotlin. The C# IDE we’re creating is written in Kotlin as well.

Gradle recently announced that they’re providing Kotlin support. In addition to Groovy, they’re now going to provide you with the ability to create Gradle scripts using Kotlin. How many of you use Gradle? They recommend that plugins are written in Kotlin. That happened earlier this year as well.

Where Can I Use It? (5:08)

Anywhere! Kotlin is not a language specifically around Android. We don’t make mobile applications; we make tools. We created a language for any kind of tool that we make, but its purpose is industrial. Any kind of application can use it.

Given that it’s compatible with Java 6 and small runtime, performance-wise it’s fine in terms of compilation. It translates into bicode.

Obviously, a lot of adoption has been gained around Android. A lot of Android developers are using it.

Given its similarity to Java, C#, JavaScript, Groovy, Scala, and every other language under the sun, it allows for a quick ramp-up time. This is not a departure akin to going from Java to Clojure, or from Java to Haskell. This is something that you are familiar with, and you’ll be able to get ramped up in no time.

Since interoperability is a big factor for us, it allows for gradual adoption. You can start to create Kotlin classes or function in your code and interop between Java and Kotlin easily. You don’t have to limit this to tests.

How Can I Use It? (6:46)

We’ve tried to make Kotlin as open and free as possible. Obviously, our long-term interest is that we continue to thrive as a tooling company and that people use Kotlin and consequently buy IntelliJ IDEA, but it is completely open. You can use it from a command line, from Maven, Gradle, Kobalt, Ant, IntelliJ IDEA, Android Studio, Eclipse, and NetBeans. You can actually open it up in the command line and write code.

DEMO: Let’s See Some Code (7:49)

To see some live coding in which I highlight Kotlin’s language features and show how to solve some common development issues, check out the video at the top of the page from 7:49-53:50. A rundown of points I touch on in the demo:

• Small runtime (~900Kb)
• Creating a class equivalent to public static void in the Java world
• Kotlin is a statically-typed language that compiles down to Java, JBM, and JavaScript
• No new keyword in Kotlin
• No getters and setters, just properties
• Top-level functions
• More than one class in a single file
• var means mutable, val means immuatable
• Overriding anything
• Giving default values to primary constructors
• Great type inference (don’t need to specify every Double)
• No need to be explicit with return type
• Simple functions (fun)
• Naming parameters, and an unlimited number of them
• Readability and expressiveness hacks
• Casting: by default, a Kotlin class is a final
• No nulls: when you declare a variable, it cannot be null
• ? and ## for nullable variables
• Interoperability
• Kotlin is a functional language
• Lambdas
• String functionality
• Extension methods
• Infix notation
• First class support for delegation
• Algebraic data types in Kotlin: the sealed modifier

ANKO (53:51)

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    verticalLayout {
        padding = dip(30)
        editText {
            hint = "Name"
            textSize = 24f
        }
        editText {
            hint = "Password"
            textSize = 24f
        }
        button("Login") {
            textSize = 26f
        }
    }
}

ANKO is an open source library which allows you to write descriptive layouts without having to use XML. It’s basically a static type language.

Android Extensions (54:07)

// Using R.layout.activity_main from the main source set
import kotlinx.android.synthetic.main.activity_main.*

public class MyActivity : Activity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        textView.setText("Hello, world!") // Instead of findView(R.id.textView) as TextView
    }
}

The compiler comes with a plugin ability so you can change some things. If you’re familiar with Android development, a lot of times you have to do findView(R.id.textView) as TextView and then cast it. With this plugin, it will allow you to reference the type.

Spring Boot (54:57)

One of the issues that Spring developers have with Kotlin is that they have to decorate everything with open. We’re going to be releasing a plugin (for any build to Maven, Gradle, et cetera) which you can use to annotate certain classes. If they have this annotation, by default they’re open, which makes it more concise when writing Spring. Spring Boot already has support for Kotlin, so you could use it to generate your templates.

Kobalt (55:03)

import com.beust.kobalt.*
import com.beust.kobalt.plugin.java.*
import com.beust.kobalt.plugin.packaging.*
import com.beust.kobalt.plugin.publish.*

val jcommander = project {
    name = "jcommander"
    group = "com.beust"
    artifactId = nameversion = "1.52"

    dependenciesTest {
        compile("org.testng:testng:6.9.5")
    }

    assemble {
        mavenJars {
        }
    }

    bintray {
        publish = false
    }
}

Kobalt is a flavor of Gradle using Kotlin to define builds.

SPEK (55:09)

Elegant DSL to clearly describe your specifications:

class CalculatorConsoleSpecs : Spek() {
    init {
        given("a calculator") {
            val calculator = SampleCalculator()
            on("calling sum with two numbers") {
                val sum = calculator.sum(2, 4)
                it("should return the result of adding the first number to the second number") {
                    shouldEqual(6, sum)
                }
            }
            on("calling subtract with two numbers") {
                val subtract = calculator.subtract(4, 2)
                it("should return the result of subtracting the second number from the first number") {
                    shouldEqual(2, subtract)
                }
            }
        }
    }
}

SPEK is a library or a testing framework that I’ve written which is kind of similar to Jasmine.

Roadmap (55:20)

Note: this is not a public commitment.

• Coroutines (async/await)
• Data Class Hierarchies
• Type Aliases
• Deconstructing in Lambdas
• Bound Method References
• Local Delegated Properties
• Java 8/9 Support
• JavaScript Support

If you’re familiar with JavaScript and the roadmap coroutines, we’re basically implementing a generic coroutine. In terms of asynchronous programming, we have implemented coroutines and we provide a series of out-of-the-box functionality as a part of the standard library, which the compiler then transforms into state machines. You can use async/await or anything you want and not be bound to a specific type.

We still are committed to providing Java 6 support, but if you’re targeting Java 8 or 9, we will improve in terms of code optimization and certain functionality that is provided as part of the standard library.

As for JavaScript support, we are now started on Native, so there will be Kotlin to Native. It’s kind of in the early stages right now, but we’ve already got something in the works.

Next Steps (56:26)

If you are interested, check out kotlinlang.org or try.kotlinlang.org, which is an in-browser IDE that allows you to try a series of exercises to get you familiar with Kotlin syntax without having to download or install anything. If you want to download them, they’re also available on GitHub.

Books (56:42)

There is Kotlin for Android Developers, and Kotlin in Action, and I’ve just finished a nine hour Kotlin O’Reilly course.

Community (57:06)

There is a very active community on Slack. You will get help there, as well as in our forums.

Summary (57:25)

To summarize, we tried to create a very pragmatic language that has a very easy learning curve. It interoperates with Java, so it provides a low-risk adoption. You don’t have to limit it to tests; you can just mix and match classes. In fact, if you use IntelliJ, you can take a Java class and through a keyboard action convert it to Kotlin code. It’s not the most idiomatic Kotlin code, but it does give you a starting point. Coming from C# and having stayed away from Java, I do find it enjoyable.

If you’re thinking why IntelliJ over Eclipse, my response is: try it! If it suits you and if you find it better for your needs, then great. If not, don’t use it. Our commitment to Kotlin is that it’s here to stay because we’re using it in our products. The business model around Kotlin is JetBrains tooling, not consulting.