Q&A With Kotlin Lead Language Designer Andrey Breslav
With Kotlin 1.0 having just been released, Andrey Breslav takes a moment to answer a few questions about this new and exciting language.
Join the DZone community and get the full member experience.Join For Free
How do you see Kotlin positioned with respect to other JVM based languages?
There are multiple JVM languages at the moment that, like Kotlin, offer type-safety and expressiveness. I think that the unique qualities of Kotlin are the combination of interoperability and “toolability”.
First, we re-use as much of the libraries and the infrastructure as possible to make transitions and mixed projects easier. For example, we rely on JDK collections (but make them nicer with some compiler magic), use Maven and Gradle for package management and builds, and avoid runtime magic like custom class loaders, etc.
Second, we believe that tooling matters a lot for productivity, and when we design language features, we have to keep IDEs, builds and other tools in mind. If, for example, something will slow down incremental compilation or require an IDE to eat up too much resources, it's a strong vote against.
Another thing is that we think that all members of a team should be equal in terms of language features that they can use, so the set of features we have is as good for library writers as for application writers. One can call this a “democratic” approach to language design. :)
As far as I can see, many people find these things important (others don't care of course, and everyone is free to make their own choice).
I would like to note here that sometimes discussions about "language A vs language B" get unnecessarily emotional. First of all, we all know that there's no silver bullet. Then, sometimes differences between language designs are simply irrelevant to the particular use case, which leaves the choice largely to one's taste. Which is fine. I think that being aware of this situation — that one simply likes this language more, and no argument is necessary at all — could alone be a big win sometimes.
Do you see Kotlin being used to consolidate the often separate languages used by backend and frontend teams?
What features of Kotlin would you name as distinguishing or most appealing?
First, there's a "basic set": properties, primary constructors, type inference for declarations, and function calls, lambdas, etc. These are almost "commonplace" features nowadays.
Then, some things that are more on the unique side (at least among the more visible JVM languages): delegated properties, extension functions (Scala does something similar through "implicit classes"), type-safe builders. These features add a lot of value by raising the level of abstraction and therefore amount of code reuse. For example, there is no such thing in the language as "lazy properties", they are simply a library construct implemented through delegated properties, and many other property behaviors are too. Type-safe builders are not really a language feature, but a pattern that relies on first class extension functions: by combining lambdas and extensions one can construct very powerful DSLs with great re-use qualities. For example, UI and templating frameworks based on builders are unique in terms of combining type-safety and flexibility.
It was never a goal for us to invent everything from scratch. We are happy learning from other languages: from Java and Scala to C# and Gosu. We ended up inventing some things and adapting others to our setting, but I believe it is not only the features themselves (or their absence), but how they are fitted together, that makes a good language.
How are you measuring the success of Kotlin as a project?
For me, it's adoption. If people choose it, then it's good. (The opposite doesn't necessarily hold, but that's an excuse I'm hoping not to resort to :) ) When Kotlin gets 100,000 active users, I'll say we have a confirmation that we did hit the sweet spot. Currently we have much less than that: about 11'000 users a month, but these numbers are growing, so we'll see :)
Opinions expressed by DZone contributors are their own.