Kotlin development is heading towards version 1.1; Kotlin lead language designer Andrey Breslav explained the roadmap to JetBrains’ JVM language new version, which will include major new language features.
Kotlin 1.1 will provides a number of new language features:
-
type aliases are meant to be an abbreviation mechanisms for longer types declarations, such as function signatures; type aliases will not introduce new types and can be used interchangeably with the original definition.
-
bound method references will be extended to support taking a reference to a member of an object. In this way, you can take a reference to the
equalsmethod of aStringobject and assign it to a predicate to use it later:val p: Predicate<String> = “foo”::equals. Kotlin 1.0.x already supports this for types. -
delegated properties will be allowed at the top level, in a class, or in a function:
fun foo() { val lazyBar by lazy { ... } while (...) { if (...) { lazyBar.doBaz() ... } } }Delegated properties are a mechanism to implement once and for all certain kinds of properties, such as lazy, observable, and map-stored properties, so they do not need be implemented each time.
-
data classes will support inheritance, thus making it possible to derive a data class from another. Data classes are classes that just hold data, and for which Kotlin automatically generates accessors,
equals,hashCode, and other common methods. This will also make it possible to extend a data class from within a sealed class:sealed class C() { data class Example(...) : C() } -
destructuring will allow to assign composed names to arguments of lambdas, such as in the following example, where the argument to
forEach, a pair, is destructured in its two components:myMap.forEach { (k, v) -> println(“$k => $v”) } -
coroutines will provide the backbone for Kotlin async behaviour. According to Breslav, coroutines are more general than the
async/awaitmodel introduced in C# 5. Kotlin will also provideasync/await, but built on top of coroutines, not as primitives:fun loadImage(url: URL) = async { val bytes = await(loadBytes(url)) bytesToImage(bytes) }
On the tooling front, Kotlin 1.1 will include direct support for Java 8/9 features, such as default method generation. Additionally, the JavaScript backend will be brought in line with the actual set of language features.
Kotlin development is driven by the Kotlin Evolution and Enhancement Process (KEEP), based on a GitHub repository where all planned use cases are described.
Kotlin 1.1 will be both source and binary compatible with previous versions, meaning that new versions of Kotlin compiler will not break compatibility with older source code and binaries.
Community comments
Illegible code
by Javier Paniza,
Re: Illegible code
by Luke deGruchy,
Re: Illegible code
by William Smith,
Re: Illegible code
by Luke deGruchy,
Re: Illegible code
by Javier Paniza,
Re: Illegible code
by Jan Kovar,
Re: Illegible code
by Javier Paniza,
Re: Illegible code
by Sergio De Simone,
Re: Illegible code
by Chandan T P,
Re: Illegible code
by mirc mircus,
Illegible code
by Javier Paniza,
Your message is awaiting moderation. Thank you for participating in the discussion.
Features such as type aliases and bound method references made the code more illegible. New languages are obsessed to be very succint (you want to save the poor programmer to type many letters), not to be as Java (verbose). This is an error because in real life we expend most of our time reading code, not writing, and many time reading code written by others, then type aliases and bound method references are very inconvenient, then a verbose language is better.
Re: Illegible code
by Luke deGruchy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Not all new languages are excessively terse.
Re: Illegible code
by William Smith,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1 - I think as an industry we obsess about “developer productivity” but it’s totally the wrong thing to think about. If your code is successful it will be in production for years, and need maintaining. Java is great for this because the code is incredibly easy to follow - I don’t know another language like this. Even c#, which is at root the same language, doesn’t manage it due to the overwhelming Scala like number of features.
Actually I’m puzzled by Kotlin generally. As with Red Hat’s Ceylon I just can’t see what it’s for. I guess when Java stagnated, during the dying days of Sun, it was tempting to think we need a new JVM language - particularly if you didn’t like Scala. But what is the UVP for Kotlin? Ok it has a more terse syntax than Java (which I consider a weakness not a strength) but why would I/should I invest time learning it?
Re: Illegible code
by Luke deGruchy,
Your message is awaiting moderation. Thank you for participating in the discussion.
Newer languages have newer features according to more modern design principals instead of those from 20 years ago.
Re: Illegible code
by Javier Paniza,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Luke, "newer" is not synonymous of "better". Only from time to time a newer thing is also better. However, for a programmer "newer" is always better, because they are always looking for intelectual challenges, not matter if they are not practical, no matter if they ignore the user.
Re: Illegible code
by Jan Kovar,
Your message is awaiting moderation. Thank you for participating in the discussion.
Illegible code can be written in any language whether it is Java or Kotlin. However the code written in Kotlin will be shorter and therefore easier to understand and refactor than the similar piece of code written in Java.
Re: Illegible code
by Sergio De Simone,
Your message is awaiting moderation. Thank you for participating in the discussion.
While I understand there is a risk that features such as type aliases could be used wrongly, it is also true that there are cases where they could help making code more readable. Specifically in the case that is mentioned with type aliases, i.e., function declarations: you could use a symbolic name that expresses the intent of your function (e.g., a callback to a network request) instead of just describing its parameters. So, I think your mileage may vary a lot depending on how you use that feature, as well as on how clever your naming conventions are.
Re: Illegible code
by Javier Paniza,
Your message is awaiting moderation. Thank you for participating in the discussion.
Ha, ha, ha...
Try to read a chunk of COBOL code then try to read a chunk of RPG code. Which is more verbose? Which is easier to understanda?
Re: Illegible code
by Chandan T P,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1. Language features that make code concise at the cost of readability is not a good thing.
Re: Illegible code
by mirc mircus,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1