One year ago Kotlin was announced as a first-class supported language for Android. For many this was the first time we heard about Kotlin. And it seemed to be the holy grail of programming languages.
Not only did Kotlin have modern features, it also seemed to be evolving very fast. There was a Kotlin language features survey, which was very timely released shortly before the announcement at Google IO. A dream come true: Kotlin developers care for our opinions and try to satisfy them.
One year has past since those early days many of us learned about Kotlin. And the promise of fast language evolution was not kept. Sure, there is lots of development regarding Kotlin API, tooling and frameworks, like Kotin’s great coroutines, Kotlin Native, Kotlin JS, multi platform projects, IntelliJ plugin etc. But there is no visible development regarding language features.
What happened to the language features survey? What happened to the openness regarding language feature plans that we faced a year ago?
Here is the future feature survey and this outline’s future kotlin features. Most of which they are still working through.
As far as the fast moving features. Well the fact is the as languages evolve you don’t want them adding and deprecating features as quickly because the language is becoming stable.
I do not think that language evolution is the main goal of development. The language is complete by now and introducing something new should not be done without a lot of thinking. Kotlin team is focusing on libraries and tooling, and I think it a right way. There is a lot of progress in that direction. Just look at coroutines and serialization libraries.
As for so-called features, lets see the top votes in the survey:
Collection literals. There is a lot of discussion around about that. Groovy style collection literals are not compatible with Kotlin syntax. So discussion is ongoin on how to do it without breaking anything. You can contribute if you want.
SAM conversion for Kotlin classes. It is also a cosmetic change and as far as I can understand, there are some internal compiler problems there. This feature is nice to have, but I am not sure it is crucial for development.
Immutable data. I think, there is a lot of progress there. The problem is that JVM does not support true immutability, so it is not easy to enforce it at least when parts of code are written in Java.
That’s what I was saying. It does not look like they are doing it at all currently. Whereas one year ago, it looked pretty different. Lots of new developers were lured in on that premise.
The language is complete, until the next language comes around the corner that has more and better features. @elizarov posted a Medium article in which he explains why he is not excited about new language features in Java. What he (presumably) meant is, for him the Java language was obsoleted by Kotlin. Java language simply evolved too slowly, and lost to the competition. Let’s not wait for a language that obsoletes Kotlin.
I know there is lot’s of progress in tooling and libraries. Again, this is what I said. This post is not about that.
I do not think that lots of developers were “lured” into Kotlin because of the promise of new features. They picked it up because it is a better java and easier to learn than Scala.
There are lots of languages out there which are older than Java and still able to drive innovation (eg. Haskell, ML). Which goes to show that a well founded language does not need constant innovation to stay relevant.
Kotlin development has one very important feature that sometimes goes unnoticed. The language constructed in a way that a lot of features could be implemented on library level without introducing new constructs in the language itself. I think it is very important and anything that could be implemented without changing the language should be implemented without changing the language.
For example, coroutines are using only one single new keyword. Everything else in libraries. Same goes for serialization. Personally, I want for kotlin to keep this tradition and not to go the way C++ or Scala goes, introducing a lot of new syntax. For example, there was a very hot discussion about collection literals and in the end, I think it brings more problems, than it solves. Simply writing listof is not so time consuming.
Slightly off-topic, but Kotlin already has syntax for collection literals, it’s just invalid outside of annotations. The compiler will even tell you that if you try.
The proposal is to define behaviour for collection literals in code.
I think much of this would be addressed if there was a public short-term road-map. Perhaps there is some improvements in the works that we’re just not aware of. The road-map could have a disclaimer specifying that these are not guarantees but simply a direction of the features that they’re experimenting with.