The Future Development Of Kotlin
Written by Mike James   
Wednesday, 28 June 2017

With Google's promotion of Kotlin to a supported Android language, the way that it is going to develop is much more important. We now have the results of the JetBrain's survey of what programmers want in the language. 


From a survey conducted in April with 850 respondents JetBrains hopes to work out what programmers want next in Kotlin. Of course, the survey happened before May's announcement that Kotlin had become an official Android language so it is interesting to speculate how many responses the survey would get now and how much the results would change. 

The three clear leaders, according to JetBrains, are:


  • Collection literals

    Collections in Kotlin are created by calling library functions, such as:

    listOf(1, 2, 3)
    mapOf(“foo” to “bar”, “baz” to “roo”)
    This could be made more convenient by adding specialized syntax, e.g. [1, 2, 3] for an array, and something like:
    [“foo” = “bar”, “baz” = “roo”]

  • SAM conversions for Kotlin interfaces

    Interfaces that have a Single Abstract Method (SAM-interfaces) can be naturally implemented by lambdas. This is how lambdas work in Java 8: when it’s assigned to an SAM interface, it implements it. This is called a SAM conversion.
    Kotlin has SAM conversions for Java interfaces. But for an interface defined in Kotlin you can’t assign a lambda directly to it. The proposal is to allow assigning lambdas to SAM interfaces:

    interface Action<T> {
    fun run(data: T)
    val action: Action<T> = { data -> log(“data:                                           $data”) }
  • Truly immutable data

    Kotlin has immutable variables (val as oposed to var), but no language mechanisms that would guarantee true “deep” immutability of the state. If a val references a mutable object, it’s contents can be modified. A val is just a read only variable so you can still change object properties:
    val myVal = arrayListOf(1)
    myVal.add(2) // mutation
    Read-only interfaces for collections help somewhat, but we’d need something like a readonly or immutable modifier for all types to ensure true immutability. Something like:
    Syntax is purely provisional:
    class Foo(var v: Int)
    immutable class Bar(val foo: Foo)
    // error: mutable reference from immutable class

These three seem minor and helpful changes. The next three most wanted changes were:

  • Slices for lists and arrays
    This would give a Python like notation e.g. data[a:b] means sub-list from a to b-1
  • Inline/value classes
    This would be essentially structs for Kotlin i.e. data classes stored by value not reference.
  • multi-catch
    Essentially allowing multiple exceptions to be caught by a single block e.g. catch (e: ExceptionA|ExceptionB)

There are no promises that any of this will be implemented and as the blog post states:

"Truly immutable data is very desirable indeed, but really tough too, so no promises there. The other two seem tractable in the foreseeable future, and multi-catch looks like a good thing to look into as well. Anyway, we will take the results into account while planning our work."

At the moment Kotlin is a nice compact language and using it reminds me a lot of the early days of C#. All languages have a tendency to bloat and accrete features that aren't strictly necessary but one programmer's "strictly necessary" is another's "can live without". Compact logical languages are best. Let's hope Kotlin stays lean and only fixes what is broken unless there is a really good case for the feature.


  • Mike James is the author of the forthcoming book The Programmers Guide To Kotlin , two chapters of which are already published on I Programmer.


More Information

Kotlin Future Features Survey Results

Related Articles

Kotlin - New Language For Android

//No Comment -  Kotlin 1.0.6 

JetBrain's Project Rider Cross-Platform IDE 

Kotlin 1.05 Released 

Kotlin JVM 1.0

Project Rider, A Cross Platform C IDE

Project Kotlin Moves On

Kotlin Goes Open Source

Kotlin - another Java alternative?

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.



IBM Launches The Granite Code LLM Series

IBM is introducing decoder-only code models for code generative tasks as part of its Granite collection. The models have been trained with code written in 116 programming languages and range in size f [ ... ]

SplitBody - Using EMS To Free Your Mind

Can automating a repetitive movement via electrical muscle stimulation reduce mental workload while users concurrently perform an unrelated task? The SplitBody research study from the University  [ ... ]

More News

C book



or email your comment to:



Last Updated ( Wednesday, 11 October 2017 )