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. 

kotlinlogo

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)
    or:
    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.

 cover

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

kotlinlogo

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.

 

Banner


Julia 1.1 Adds Array Alternative
17/10/2024

Julia 1.1 has been released with improvements including a new Memory type that provides a lower-level container as an alternative to Array.



Apache Fury Adds Optimized Serializers For Scala
31/10/2024

Apache Fury has been updated to add GraalVM native images and with optimized serializers for Scala collection. The update also reduces Scala collection serialization cost via the use of  encoding [ ... ]


More News

espbook

 

Comments




or email your comment to: comments@i-programmer.info

 <ASIN:1871962536>

 

Last Updated ( Wednesday, 11 October 2017 )