After three months in beta, the Kotlin team has announced the release of Kotlin 1.0, which aims to stabilize both API and ABI of the language.
The four beta releases leading to release candidate and then to 1.0 have brought many changes to the language, to the standard library, and to Kotlin IDE. In particular, the focus on the standard library has been to clean up its API and reduce is footprint to make it better suited for Android apps. On the language side, in addition to many changes aiming to round up the language syntax and/or semantics, the binary format has been finalized and some legacy bytecode peculiarities removed. Regarding tools, a new algorithm has been rolled out to improve dependency detection, which will make incremental compilation much faster, according to JetBrains. Additionally, the main Kotlin plugin for IntelliJ IDEA now includes the Android plugin, so Android is supported out of the box.
Andrey Breslav, lead Kotlin designer at JetBrains, also clarified what Kotlin’s plans are regarding backward compatibility. Specifically, Kotlin will strive to ensure that new code can be compiled and run against old binaries (ABI/API backward compatibility), and that old binaries can run against new binaries (ABI forward compatibility). At the source level, the goal is ensuring that new compilers will compile code that older compilers did. InfoQ has spoken with Breslav.
What were the motivations for the creation of Kotlin?
When we started in 2010, our initial motivation was that we wanted a better language to develop our products on the JVM, and we realized that many other people want the same. Some alternatives to Java existed at the time, but they didn’t quite fit our requirements (some people have different requirements, and for them those languages work perfectly). Our requirements were:
- static typing: for maintainability of large code bases;
- smooth migration path: for gradually introducing the new language to our existing code bases affecting the rest of the code as little as possible
- tooling quality: we believe that being productive with a language depends largely on the tooling;
- ease of learning and understanding: in our teams, we do not separate “library writers” from “library users”, and we want all our developers to be equally productive with the language they are using.
I would say that Kotlin is still unique on the JVM in combining all four of the qualities listed above.
Kotlin has reached 1.0. Could you summarize the meaning of this milestone?
Many people were using Kotlin even before the release, but an official 1.0 means a lot in terms of guarantees. Quite a few times people came to us saying that their organizations won’t consider adopting Kotlin until it reaches 1.0, which is perfectly understandable. Now, with 1.0 out, Kotlin “officially exists”, so one can feel safe using it in production. This is largely backed by language evolution concerns: from now on we are committed to backward compatibility, i.e. changes made in the subsequent versions of the language and the standard library won’t break the binaries compiled with the previous versions. So, when you deploy Kotlin code, you can be as sure about it as about your Java code.
Backward compatibility is the primary reason why it took us about five years to release 1.0. Before saying that we won’t make any breaking changes, we had to be sure that the our design is practical, not only elegant. And we believe that this is only possible when the language is used in production. So we used Kotlin in our own products at JetBrains for about two years by now, and we are pretty confident about it.
This is not to say that the initial design was perfect from the start: the production use at JetBrains and other projects revealed some important issues. We had time to fix those and validate the fixes further.
Svetlana Isakova described Kotlin as “Swift for Android” at DroidCon-DE. More generally, can you explain how Kotlin fits into the current programming language landscape?
“Swift for Android” is a catchy title coined initially by Mike Gouline which picked up very successfully. And the analogy is pretty fair, I would say: as for iOS developers Swift is a modern alternative to Objective-C, for Android developers Kotlin is a modern alternative to Java. But I would like to point out that Kotlin is not at all limited to Android.
In terms of platforms and domains covered, Kotlin works everywhere where Java works: desktop, server-side, mobile — anywhere. We also generate byte code compatible with Java 6 to make it usable as widely as possible. The runtime is really small (about 800K), and we are paying specific attention to avoiding any runtime tricks that would prevent Kotlin code from running somewhere (i.e. no special class loaders or run-time packaging requirements, etc). Additionally, we are working on a JavaScript back-end for Kotlin (experimental for now) that broadens Kotlin’s context of applicability quite a bit: one will be able to develop web applications entirely in Kotlin.
What’s on Kotlin’s future roadmap?
There are many things, big and small, to be done. The aforementioned JS back-end is one of the big things. Then, there’s toolchain performance. Kotlin now has incremental compilation in IntelliJ IDEA: when you change something in the code, only the affected files (not modules!) are recompiled. We want to provide the same experience to Gradle users, this is in the works. The upcoming 1.1 will be able to generate Java 8 byte code (along with Java 6), which enable many optimizations, e.g. for lambdas. In terms of language features we are not planning anything big for 1.1, but some restrictions may be lifted, e.g. for data classes. We also have some ideas about further reducing the methods count in the standard library, which is important for Android developers.
As for more far-fetching plans, we, for example, are definitely going to support Jigsaw runtime modules when they are ready, and add async/await in some future versions of Kotlin.
Kotlin 1.0 requires all code to be recompiled to clean up from code generated by previous versions. Along the same line, it makes into errors all language constructs that have been previously deprecated. It can be installed in IntelliJ IDEA through a prepackaged plugin, otherwise can be built from its GitHub repository.