Kotlin in 2020: ‘A Better Java’ Continues to Mature

Kotlin is an open-source programming language that’s often pitched as a Java replacement; it’s also a “first class” language for Android development, according to Google. Over the past few years, Kotlin has enjoyed a surge in popularity (although to be fair, it’s still only used by a fraction of the developers and engineers who use Java), but why?

It all comes down to simplicity. Scala was also designed to replace Java, but ended up hobbled by its complexity and slowness to compile. Kotlin, on the other hand, is streamlined, with some great features, and comes with a solid library. 


Kotlin might not have nearly as many users if not for Google’s choice to embrace it as a key language for Android development. Many suspect that Google’s support for the language is not unrelated to the little spat with Oracle over Java API copyright and Android. In any case, though, that support led many developers to take a second look at Kotlin.  

Although the TIOBE Index has Kotlin in 35th place, the language ranked fourth among growing languages in the 2019 Github Octoverse report. According to the annual JVM survey, Kotlin is now the second most popular programming language on the JVM.

Not bad for a language that first appeared in 2011, with Version 1.0 released just four years ago (the current version is 1.3, with 1.4 due in Spring 2020). 

Kotlin is a Better Java

Version 1.3 has a number of new features, including coroutines (a form of lightweight threads). It’s even possible to run the main function as a coroutine, but much of coroutines’ strengths lie in channels. 

These are similar to channels in Go, and allow a stream of values to be sent between coroutines, with optional buffering for storing multiple values in a channel. Channels can also be used as tickers, sending a value at regular time intervals after a value is received.

Kotlin supports multiple projects. This is possible because Kotlin code doesn’t just run on the JVM (Java Virtual Machine); there is also Kotlin/Native that produces code for iOS, tvOS, WatchOS, Android, Windows, Mac, Linux and WebAssembly (this can be done as exes or dlls with static or dynamic libraries). Code can even be shared between different platforms; note, though, that the multiplatform-projects feature is still experimental in Kotlin 1.2 and 1.3.

Other experimental features in Kotlin 1.3 include inline classes and unsigned integers. Inline classes are an optimization; for example, it’s a way to avoid the overhead of boxing primitive types such as int (a failing of Java compared to, say, languages such as C#). This is done by removing constructor calls, GC pressure, and enabling other optimizations—but there are restrictions, such as being limited to one property, so no inheritance can be done from an inline class.

Another little-known aspect of Kotlin/Native is the bidirectional interoperability with Objective-C and Swift. This lets you use Objective-C or Swift frameworks in Kotlin or Kotlin modules in Swift/Objective-C. If that’s not enough, you can also use Kotlin with C. Mappings are provided between Kotlin types and Swift or C equivalents. These languages aren’t the end; Kotlin lets you create dynamic libraries (dlls on Windows or .so on Linux etc.) so your Kotlin code can be called from any language that can use dynamic libraries. 

Version 1.4

Language changes will be few and far between in the next release, which focuses on quality and performance. This is done with the addition of a new compiler and a multiplatform library to simplify shipping code to different platforms. The new compiler will eventually replace the three separate compilers for JVM, JavaScript, and native.


For any programming language, two key factors always come into play: 

  • Are people interested in it? 
  • Is it still being worked on? 

Kotlin definitely ticks both boxes. It’s safe to say that it’s going to be around for quite a while. I wonder, though, how much actual Java code has been replaced by Kotlin on the JVM. 

Nobody does a rewrite just because a nice compatible language comes along; there has to be a commercial reason, because rewrites are not cheap. Kotlin’s strength lies in new development, in particular on Android and in established software houses where existing Java code can be reused and replaced piecemeal with Kotlin code.

WebAssembly is one area where Kotlin has the potential to do well. Though Rust is expected to become big in this area, I think Kotlin has the simplicity and power to do as well (if not better) and is currently slightly more popular than Rust. Many people know Java, so Kotlin is an easier reach than having to learn a completely new language like Rust from scratch. 

4 Responses to “Kotlin in 2020: ‘A Better Java’ Continues to Mature”

  1. developer

    Type before variable or not: in Kotlin type comes after the name of variable or function etc.
    Instead of writing Type function(AnuvverType param); I write func function(param: Anuvvertype): Type.
    Maybe that has something to do with the native language of the people who design the languages, but for me this is just plain wrong. That is why I prefer Java(C/C++) over Scala or Kotlin: the order of language elements of the syntax feel natural if type precedes name.

    • Gemsmith

      Then you never have suffered a large codebase with complex generic types like

      HashMap<RegistryKey, ViewModelElement>

      where you even as a hoary java developer totally lose orientation where the variable name is — what most of the time of code analysis and review is the more important information. (“Well, fine, I have read a complex type now, but am I even looking at the member I searched for?”)

      This is true for attributes, where the variable names of a bunch of attributes move from very left of the editor viewport to the very right of it, or even outside the view-borders (when you organise many editor windows parallel on a laptop screen).

      This is true for methods with complex generic return types and parameter types where the method name is squeezed somewhere between return type and parameterlist.
      To solve that I used a code style where the return type is written above(!) the method name so that all method names are easily visible on the left.
      A thing that is not welcomed by auto-formatters and code-style checkers.

      As Java does neither a good inference job nor provides type aliasing, the “wrong” order of type and typed-member IS an issue.