This article was originally published in Codementor.io
Kotlin is the new lovechild of the JVM developers’ world.
Google promoted Kotlin as a first class language on its Java-based Android platform back in May. Since then, the whole development world has been wondering: what is this language? Kotlin has been around for a few years and has been running on production systems, after the languages 1.0 release in February 2016, for a year or so. The language has received a lot of praise and loving words from the developer community. It is a breath of fresh air, a good upgrade to systems running older versions of Java, and still somehow an old dog in a familiar playing field.
In the next three tutorials, we will introduce you to the Kotlin language, starting from basics and making our way through the more difficult aspects of it. In this post, we will cover the syntax and other basic building blocks of the language. In Introduction to Kotlin Part 2, we will touch on variables, functions, classes, interfaces, and objects. Finally, in Part 3 we’ll look at a few examples about control flow in Kotlin.
There are a few approaches we can take when introducing Kotlin. We can discuss it through Java, the language Kotlin needs to be based on due to its JVM runtime, or we can do it through Scala, the language Kotlin is heavily influenced by. There is no doubt that Kotlin is better than Java. It is much safer and more concise. It provides you with a bunch of additions to your standard Java language and enhances a few bits and pieces that Java developers have grown to dislike. Additions include things like null safety, extension functions, data classes, objects, first class functions as well as extensive and expressive lambdas. Kotlin also enhances Java’s type inference and type system and takes massive leaps forward with collections.
Perhaps, it’s better to compare Kotlin against Scala. This comparison might scare some of you quite a bit because Scala has the reputation of being simultaneously intriguing and frightening. It heavily introduces functional programming paradigm to you while still mixing it into familiar object orientation (hence in an awfully lot of cases creating a mishmash of advanced techniques from both paradigms), brings in some new build tools, and gives your internal flow state a frustrating break every now and then due to long compile times.
I come bearing both good news and bad news. Let’s start with the bad news:
Bad news is that Kotlin is similar to Scala, it follows the same path as Scala does
The good news: luckily, it’s only slightly similar to Scala in every aspect.
The functional programming paradigm is big part of Kotlin as well. Luckily, it doesn’t go into the higher-kinded types, monadic do-continuations, or advanced type theory concepts that make you seek out Bartosz Milewski and his brilliant book on Category Theory. Kotlin introduces easy-to-use collection manipulation functions and functional pipelines for you. You will get your maps, filters, and folds, which in most cases are enough to get to the functional programming path.
Java devs that have been lucky enough to jump into Java 8 (hugs and kisses to you Android and/or enterprise developers) will be familiar with the these basics and will feel right at home when they jump into Kotlin. They will also find conciseness and safety of better type system, which will spark their first crush towards the language. It is just so pretty and seamless to pipe these functions together and build a clean pipeline. And when you come back to it after a few weeks, you’ll still feel like you can somewhat understand it. Smiles all around. :)
When developing in Kotlin, your build processes will be more or less the same as in your old Java application. Since you are already familiar with these, there is no need to learn anything new. The build process and build tools introduced by Kotlin can be described in two words: Gradle/Maven Plugin.
You can introduce the language to your codebase by adding the Kotlin plugin to your Gradle/Maven build script and making sure it points to the correct folder that defines your Kotlin files —adding Kotlin to your code base is just a quick Ctrl-C + Ctrl-V away. More information on how to make this happen can be found from the official Kotlin documentation: Maven/Gradle. That is literally it, it will just miraculously work, kinda like Apple devices [^1].
Oh, and Kotlin also clicks into place on top of your tooling seamlessly. Kotlin is made by JetBrains, the same people who created IntelliJ, the best IDE the world has ever seen, so the tooling better be spot on. And oh boy is it. IntelliJ nowadays comes bundled with a Kotlin plugin that gives you all the good stuff you expect to see when spitting out Java code. You will get brilliant intellisense, built in integration to build processes, and smart suggestions on how to make your code better — all wrapped up in a pretty and functional package.
Naturally, you’d also have plugins for your favourite IDE, if IntelliJ is not your cup of tea. These tools make Kotlin a breeze to develop in. That and the safety nets smartly built into the language make certain that there is a lesser chance of blushing from bad code quality when you’re showing your 4-year-old codebase to your coworker/boss/OS community/spouse.
As a language, Kotlin is very close to Java. This gives users a few nice little perks. For example, the interoperability between Java and Kotlin is brilliant —you can jump from one file to the next and change the language with zero barriers. Introducing Kotlin to your code base can be done incrementally because your old Java code can live side-by-side with your newer Kotlin code. Another perk we get from not deviating too far from Java is the whole compile process. Compiling Kotlin code to JVM bytecode does not take that long. Folks from Keepsafe made a nice little test to compare their Kotlin codebase with Java. Their results show that Kotlin compile times are actually faster on incremental builds than Java compile times. Blazing fast![^2] Not sad at all.
A great man once said talk is cheap, show me the code. So let’s take a shallow dive into Kotlin.
To make all blog post gods happy, we are going to start off with a simple hello world. In Kotlin, it goes a bit like this:
Now that we’ve got that out of the way, we can do some pseudo analysis on it. The syntax seems familiar so let’s assume parenthesis means a function call. There is no semicolon to end the line, which is neat. Oh, this
Alright, now that the blog gods are happy we can move forward.
Variable declaration in Kotlin can happen in a few different ways. We have keywords
var. These two look similar but have one major difference:
Values declared with
valare immutable (well, read-only) and you can only assign a value to them exactly one time. That time comes when you are declaring and creating the value or when you are assigning a value to already declared but not created one. Variables with
varare mutable and can be reassigned. The preferred way is to use
vals everywhere that is possible. This way the codebase will be easier to handle and reason about.
Notice how the type of the variable is defined after the variable, separated by a colon. There’s a good reason behind this. The compiler can now decide whether or not to infer the type, which means that Kotlin has a more powerful type inference than Java. You can actually leave the type declaration out completely and the compiler will know what you mean.
This only works when the value, and therefore the type of the value, is known.
How about functions? It’s always fun to write functions in Kotlin. Since we use the keyword
funto declare them, it’s bound to be fun! (ha ha. :( )
Type declaration follows the same pattern here —it comes last. In our first, side-effectful, function, we are not returning anything so we can omit the type, which in this case would be
Unit. In the second function, we defined that we must return a
String and we did, using the trusty
return keyword. Last one is a bit more puzzling. There are no curly brackets, just an equal sign. That means our
fun is an expression and it will return automatically.
When you’re just starting to build up functional pipelines, most people tend to lean towards these expressions. It is a way to force your functions to do one thing, and do it well. As you can see, the return type in expressions is optional and can be omitted or left in place, whatever makes you happy (rule of thumb: in long expressions, put it in, in shorter ones, it can be omitted).
Kotlin also introduces the concept of optional and named function parameters. This is useful especially if your functions grow into a monster of a lot of same types and multiple different parameters.
In this snippet, we defined our function parameters with default values. When this is done, we can just call the function with zero, one, or both of its arguments. If arguments are omitted, then the default values kick in. As you can see, we can also call the function while naming the arguments. This gives us more insight into what we are calling with which value and possibility to target individual optional argument. Note that optional arguments work for both class constructors as well as functions.
There are also neat little things like extension functions and infix functions as well as operator overloading in the language. These are interesting aspects of Kotlin that make writing the language more pleasant. These functions give us control freaks more opportunities to write beautiful code and naturally readable structures. That is a different topic for another article though.
Like Java, Kotlin has classes and interfaces. Unlike Java, Kotlin instances can all live in the same file and don’t need their own. This decision made by the Kotlin team has made code organization more pleasant and language more concise. Let’s tackle classes first.
In Kotlin, there are a handful of ways to create classes. The first example in the snippet reveals a few things to us:
Naming convention starts with a Capital letter
There are no curly braces
There is no visibility modifier in this example
We still use the
In Kotlin we instantiate these classes nearly the same way as we do in Java, except, we omit the
new keyword. Like this:
We have now instantiated a class that we can do nothing with. Good job!
The second example is similar, but it has a constructor. Notice how the constructor is bundled into the same line as the class (you can leave the
constructor keyword out in most cases, it only needs to be added if the class has annotations or visibility modifiers), another way to make Kotlin code more succinct. When we instantiate this class, we need to pass in the value for
Properties in Kotlin are public by default, so there is a simple way to access this property:
This class doesn’t have any functionality; it is just a vessel for our data. We can add some functionality in there by defining
funs inside the class. In this case, we need to attach those beautiful curly braces into our declaration.
You can more or less dump the same things you would in Java to a class here. We can attach properties, other classes, extra constructors or initialization blocks in and we can assign visibility modifiers to all of them individually.
Init blocks in Kotlin can be used to do things you would normally do with your Java constructor. If you want to create a class within a class, you can mark it with the
inner keyword to be able to access members of the surrounding class.
Here, we have a few moving parts. By using the
lateinit keyword, we can tell the compiler that this property is not null, even though we don’t initialize it right away. This is useful for cases where we don’t initialize our properties in the constructor but use, for example, a dependency injection framework to assign values to them. Note that our
lateinit property is mutable — this is a must.
init is equivalent to the constructor block in Java classes. In there, we can perform needed actions when we instantiate the class. In this case, we assign a String to our property, something that could be done as a joined assignment as well.
Next, we have a function that finally assigns a value to our
lateinit property, instantiating an inner class
CanadianPerson. This inner class is just a vessel to our data once again.
Finally, we’ll have a function that we invoke: this function will return a String, which it parsed together using string interpolation. The dollar sign character can be used in Strings to replace the $-prefixed property name with its toString implementation, defined in that property.
When adding additional constructors to the class, we need to make them call the original constructor.
Now that we have gone through classes with some functionality in them, we can take a look at some simpler classes that do nothing other than hold our data.
For these kind of data transfer objects, Kotlin has introduced a keyword to define them:
data class. It differs from standard classes in a few ways. A
data class automatically generates
copy functions. The first three of these are familiar for Java devs, the fourth one is a nice addition that helps us create similar objects from our read-only data class. The
copy function can be used to do that.
In this case, our peeta object contains a
num 3 and an
str “Goodbye”. Neat!
We also get
component functions to the data class for free. These component functions are a way to access the data within our data class via destructuring. This helps take individual properties from our data classes with a succinct one line call.
With this trick, we have variables
num and their values are “Goodbye” and 3 respectively. Note that the order of destructuring variables depends on the order of the properties in our data class; the names don’t actually matter at all.
Two other top level structures are
Interfaces in Kotlin don’t differ that much from the Java world. One nice thing is that you can have abstract properties in your interfaces as well. These properties need to be initialized in the implementing class to honor the contract of the interface.
As you can see, this is very similar to Java. Like Java 8, Kotlin also can have default implementations in interfaces. We can achieve the same thing shown above with this interface.
Using this, we don’t have to override the function in our implementing class. Notice that the
override keyword is mandatory in Kotlin. This helps us, users of someone else’s’ code, appreciate the fact that the contract of the function/property comes from somewhere outside of our implementation. Good way to dodge responsibility XD
What is this then? In Kotlin, you can create singletons with
object keyword. This is a nice pattern to store, for example, a larger context of your application in a single place. You could instantiate a bunch of complex classes and hold those objects in a place where they can be accessed easily. You can access functions in objects by calling their names directly.
The companion object is a slightly different beast. It is defined within a class, which is still a singleton, and it can be accessed using the name of the wrapping class.
That’s a short introduction to classes in Kotlin. There are quite a bit more we can discuss on classes, but to keep this post short, we’ll postpone
generics, and others for a future post.
Now that we have variables, functions, and classes nailed down with a decorated fluffy hammer, we can take a short look at some control structures in Kotlin.
If statements in Kotlin work more or less the same way as in Java. There is one big and important difference that is worthy to be pointed out:
This looks exactly the same as in Java. Suprise! It is! The next one is a bit more puzzling.
If statements in Kotlin are actually expressions. They return the last value within their block, so in this case, the String value written in it. This brings a few caveats with it. Because you can use these
ifs the same way as ternary (the trusted
val thing = three > 4 ? "What?" : "Nowei!?") operators, Kotlin guys have actually omitted ternary completely. Therefore, if you are trying to hunt that question mark on your keyboard, don’t. There is a whole different meaning to that symbol in Kotlin. We’ll touch on question marks in the next post.
If clauses’ best friend
switch-case has the same fate as ternary operator. It has been replaced by
when statement in Kotlin.
As you can see
else clause replaced the
default case, and arrow replaced the
: character. Keyword
break is not needed anymore since
when expression will stop when it hits the first true case. We can also wrap each of these cases with squiggly brackets — in those cases, just like in
if expression, the last statement of the block will be returned. There are a few interesting aspects of these
when expressions. They can be evaluated using any kind of expressions, many cases can be bundled together and for numeric values, you can use ranges to determine the clause.
We can also omit the parenthesis and the passed in value from our
when completely and squint really hard. If we look from the correct angle, we can make our when expressions look like
ifs and subsequently replace them completely.
Hold up! You must be thinking. “What’s that double dot in there that we skipped past completely?”. That’s a range expression in Kotlin, it’s one of the building blocks for
for statements in the language. Now, after a while (not the loop [hehe]), for loops won’t play a big part in the language since the collection extension functions make simple loops in many cases useless. Let’s skim through them regardless to wrap up this article.
That looks straight forward enough. In the first one, we used the magical
in keyword to take a value from
range that we defined with double-dot and assigned that to
i. Next loop adds a
step keyword which indicates that we want to take every other value from the range. The third example loop takes values from a list (that we have created with a function call to
listOf) and prints them out. That is more or less for-loops in Kotlin.
Those are the basic building blocks for the Kotlin language. With these, you can start to write and play around with the language. We left out some essentials like lambdas, null-safety, and types. We didn’t touch on collections yet either since they need their own chapter and is better to touch on after we’ve covered lambdas. Hopefully by the end of this post, you now have an idea about Kotlin and its basic syntax. In the next article, we will ramp up the magic and expose more aspects that make Kotlin such a loved language amongst developers targeting JVM.
Don’t forget to check out the other posts from this series. In Introduction to Kotlin Part 2, I will introduce you to null safety, lambdas, collections, and types as well as few handy utility functions in Kotlin language.
In Part 3, we will wrap up the introduction with extension functions, higher order functions, and functional style, and finally introduce you to generics and delegates.
[^1]: Only in unison with other Apple devices (apart from the latest generation, which sometimes works). Actually, let’s say it works better than Apple devices, because that’s closer to truth. And Kotlin is also pretty, like Apple devices, yes. Let’s say that Kotlin is pretty like Apple devices and just works like anything Linus has made. That’s a much better analogy.
[^2]: Yes, with an asterisk naturally. And yes yes Go people it is not the fastest in the universe, just remember we are still running on a JVM. Let’s hope your dependency URLs stay online.