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) 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.
Mike James is the author of the forthcoming book The Programmers Guide To Kotlin , two chapters of which are already published on I Programmer.
Apollo has added a simpler way to integrate REST APIs into a federated GraphQL environment. Available now in public preview, can be used to map REST API endpoints to their GraphQL schema using a decla [ ... ]
At last ISO C23 has been published, but at $250 you probably aren't going to read it. Can we really tolerate this sort of profiteering on the work of others? This is worse than academic publishing!
