10 reasons to use Kotlin

Kotlin’s a great language with which to develop general-purpose and mobile applications. Here are some handy reasons you should consider using Kotlin with or instead of Java, without losing the JVM itself:

1. It’s very expressive. Writing code in Kotlin tends to have a high impact per line of code, without losing meaning (no magic “super-keywords” that do more than one might expect).
2. It works well with the JVM and Javascript. It generates bytecode for the JVM as an output, so you get the modern JVM’s performance benefits. You can also target multiple platforms, so if you’re willing to accept certain limitations in library availability or portability, you can target Javascript as a runtime, or native code, as well as the JVM.
3. It has top-level functions. You’re no longer quite as limited to “everything must be in a class” as in Java. This is a JVM limitation; Kotlin has sane workarounds. Not only can you introduce top-level functions, but you can introduce scoped visibility of other functions, which enables use of “companion objects” that encapsulate functionality cleanly at the source level.
4. It’s a tidier language vs. Java. Kotlin uses the same language models as Java without being as verbose about them. If you know how to write good Java, you can innately write “good Kotlin” but without all of the same boilerplate. In fact, that’s part of why IDEs such as IntelliJ IDEA can create workable, generally worthwhile Kotlin from Java code. Such tools look at what the Java code is trying to do, and simply emit Kotlin to do the same things. Is it idiomatic? Not always, but usually so.
5. Operator overloading is possible. It’s not even difficult, and enables you to introduce sane vector and matrix types, for example, without having to resort to BigDecimal’s plus and minus It’s the weapon with which to shoot yourself in the foot that you’ve always wished from Java!
6. Embrace localized functionality. You can extend classes and add methods and state to create proper localized functionality. If you need to add a method to List to extract every other entry, for example, you can do it, and you can even scope that functionality as needed.
7. You can reuse Java libraries with Kotlin. Using existing Java libraries is largely transparent for Kotlin. If a library exists for Java, you can use it in Kotlin without the impedance mismatch at the source level you’ll find from programming language options such as Scala.
8. You can use a Kotlin library from Java. This offers the same benefit as Java libraries in Kotlin: it’s relatively easy to create a Kotlin library that can be used from Java without feeling alien. There are a few cases where you can tell that you’re calling a Kotlin method at the source level, but not many.
9. Don’t fret about dependency or impedence. Kotlin’s runtime library is fairly small (2MB), so the runtime dependency impact is easily tolerable. There are a few cases where Kotlin’s libraries have an impedance mismatch with the JVM, but they’re usually caused by multiplatform libraries. Even those are not large; they just slightly change the requirements of how you design, and most developers would not notice.
10. There’s actual null safety at the language level. It can be circumvented, but at least it’s there, and at least the circumvention is obvious at the source level. Not only do you have the elvis operator (an operator that continues evaluation if the reference is not null) but you have scoping functions including let, run, apply, also, and with that enable you to write elegant code without the repetition Java would require.

Kotlin and Java are similar by design, but they have several key differences.

Kotlin was designed as a language that expressed many Java idioms cleanly, and bundles in a lot of functionality that Java coders have wished they’d had all along. Java is adding Kotlin features as it advances — Java 21 is quite impressive in a lot of ways — but it is still playing catch-up. Moreover, many of Java’s improvements still have to live alongside older Java idioms that Kotlin’s does not encounter.