The very first programming language that we experimented with for the Adventurous Developer’s Guide to JVM Languages report was Kotlin, the JVM programming language developed by JetBrains. Kotlin features nice syntactic sugar, strong IDE support and combines the best features from other programming languages. This time we had an honour to interview Andrey Breslav, the Kotlin project lead.
RebelLabs: How do you describe Kotlin?
We think of Kotlin as a modern language for industry: it is focused on flexible abstractions for code reuse and readability, static type safety for early error detection and explicit capturing of intent for maintainability and clarity.
One of the most important use cases for Kotlin is a big Java codebase whose developers want a better language: you can mix Java and Kotlin freely and migration can be gradual and doesn’t have to alter entire codebase.
RebelLabs: How did you come up with the idea of a new programming language for JVM?
Andrey: We have a huge Java codebase developed over a decade, IntelliJ IDEA, and we wanted to switch to a better language without abandoning the code we already have.
After examining existing alternatives, we found that none of them fulfills our requirements (that are rather moderate: smooth integration with the existing infrastructure, efficient tooling possible, good compiler and run-time performance), and as we believe that we are not unique in this sense, we decided to leverage our expertise in programming languages (seven IDEs on the market today, and each one is almost a compiler), and create a language that people need.
RebelLabs: What was the programming language that inspired Kotlin the most?
Andrey: It’s hard to name only one. Java, Scala, C#, Groovy were the biggest influencers. We also learned from many others, including Objective-C, Gosu, Spec#, Python, Eiffel and so on.
RebelLabs: Are you excited about the features (lambdas, defender methods) in Java 8?
Andrey: Sure. Java getting better means millions of developers getting happier. Kotlin can make some of them even more happy, but it’s another story :)
RebelLabs: What are the features you would like to see in Java.next?
Andrey: Declaration-site variance and some way of storing collections of primitives without so much performance overhead.
RebelLabs: Probably it is too early to talk about adoption since Kotlin haven’t reached its 1.0 version yet, but nevertheless: do you think Java 8 (or Java.next) will affect adoption of Kotlin in any way?
Andrey: People who only need “Java with closures” will get it with Java 8 and be happy. But there are other people, who need more than just anonymous functions (that are very important indeed, but the world does not end there).
RebelLabs: Jigsaw was dropped from Java 8… What are the plans for Kotlin in regards to modularity?
Andrey: We find it impractical to tie a language to any runtime modularity mechanism, so we provide compile-time modularity for dependency and visibility management, and that’s it until Jigsaw comes out.
RebelLabs: How hard it is to get Java interop working for Kotlin? What are the main challenges?
Andrey: For the user it’s very easy: just works out of the box. For us, it’s a lot of work. The challenges include using Java classes in a smart way while they lack the necessary type information: nullability, declaration-site variance, mutability of collections and such.
Currently we are working on a tool that performs additional analyses on Java binaries and thus infers more precise type information.
Other challenges concern well-known design mistakes made mostly in Java’s early days, like covariant arrays and such.
RebelLabs: If you had an opportunity to design Kotlin from scratch again, what would you do differently?
Andrey: I would think faster and make no mistakes I’ve made and had to correct later :)
RebelLabs: Some JVM languages seem to have a bit different approach to the “billion dollar mistake” (ie null values). What is the rationale for Kotlin to approach this?
Andrey: Kotlin uses a notion of a “nullable type”. References in Kotlin do not admit nulls by default, you have to specify nullability explicitly in the type. You are not allowed to dereference a nullable pointer without an explicit check. This effectively guarantees NPE-free code, unless you do really bad things, e.g. use Java to throw bad data at Kotlin, and even then we blow up early and give reasonable error messages.
RebelLabs: Is there a particular aspect of Kotlin you would like to emphasize?
Andrey: Too many of them! But I’ll tell about one here: tackling declarative data with builders. Builders were something only possible in dynamic languages before we Kotlin supported them in a completely type-safe way.
For example, you can write type-safe HTML and CSS in Kotlin and have true reuse of declarative structures (as opposed to rather cumbersome and sometimes limited template languages and LESS/SASS). The Kara web framework is doing a rather good job there. It’s under development, but what they have so far is very impressive.
Just google for “Kotlin Builders”, you’ll like it.
RebelLabs: Programming language design is about compromises. Is there any feature that you had to drop because it didn’t fit your constraints or because of JVM limitations?
Andrey: Most notably – reified generics. It turns out that we’d have to completely spoil Java interop to implement them, and considering the relatively little benefit they bring, it’s not worth it.
RebelLabs: It looks like that most of the recent JVM languages take advantage of static types. Have statically typed languages win the race?
Andrey: I don’t think there can be a winner there. There was a lot of confusion, because old statically typed languages had no/little type inference, so they became too verbose and ugly. Modern statically typed languages look almost as nice as their dynamic rivals, but provide better tooling support and runtime performance.
On the other hand, there’s a lot of “dynamic magic” some people like so much, and quite a lot of it is not possible in a statically typed language. That’s why many statically typed language introduce “dynamic types” or something similar.
I think eventually everyone finds their niche: dynamic languages for small, short-lived, quickly written projects, static ones for bigger, longer-lived, more effort-demanding ones.
RebelLabs: How do you see the JVM languages landscape in 5 years?
Andrey: Java’s market share will be smaller, i.e. in total, other languages will attract more people than today, but it’s hard to say who will get what.
RebelLabs: In your opinion, how important is the toolset for the programming language (in respect to Kotlin)?
Andrey: In general it depends on what your project is. If you have many developers working on a long-lived project, the tooling is very important, since you simply have a lot of code to maintain, i.e. browse through and refactor. And Kotlin is targeted at this kind of projects.
RebelLabs: Can you suggest any good reading for the wannabe language designers?
Andrey: Steven Muchnick’s “Advanced Compiler Design and Implementation”, Benjamin C. Pierce’s “Types and Programming Languages”, and of course, Dostoyevsky’s “Crime and Punishment” – it’s a very good book and no language designer should miss it.