Results of the Kotlin Features Survey 2021
A few months ago we held the second poll for the most awaited features in Kotlin. The main goal of this research was to find out what you thought about the relative importance of future Kotlin features and the diversity of user scenarios. This research will help us to prioritize our long-term language development plans. We’d like to thank everyone who participated and answered the questions!
Below you can find the results of the survey and a write-up from Roman Elizarov, Project lead for Kotlin, about our plans for the top-voted features. For additional information, please check out the feature descriptions and the webinar with Roman Elizarov and Svetlana Isakova.
Please note that this survey was not exhaustive. It did not cover features we are currently working on, and even the features included in the survey are at various stages of development. We cannot promise that any of these features will make it into the language any time soon, even if they have received a lot of votes. You also won’t see any of them in the1.6.x versions, as your votes help us to prioritize our work over the long term.
The survey asked respondents to do three things:
- Choose up to 3 features that they would like to see added to the language (mandatory selection).
- Identify one feature they would never like to see implemented (optional selection).
- Clarify why they would not like having this feature in the language (optional).
We also gave respondents the option to share information about how many years of experience they have with Kotlin, their goals for using Kotlin, and the types of software development they do with Kotlin, which helped us to understand the nature of the use cases better.
We received 1,540 complete responses. The anonymized raw data is available, just in case you feel like diving deeper into it.
The most wanted features
The top 3 features are as follows:
- Multicatch and union types (45%)
- Collection literals (32%)
- Multiple receivers on extension functions and properties (30%)
However, the features taking the 4th through 9th places on the list were also heavily upvoted by the community. The six features at the bottom of the list all received noticeably fewer votes. Some of them also ended up in the top 3 most unwanted features, like Lateinit for nullable and primitive types and Overloadable bitwise operators like I and &.
Since there is also more than one way to implement the Multicatch and union types feature, we asked the Kotlin community to share which of the two possible implementations they’d prefer:
- 87% voted in support of union types; this would make it possible to declare a function returning one of the possible values without having to introduce a dedicated
ParseResulttype at all. - 13% suggested that we not make any specific changes for exceptions because modern Java APIs don’t abuse exceptions that much (and older ones will eventually be superseded). They would prefer to have a concise enum-like syntax for declaring sealed classes, so that Kotlin-style error-returning functions are easier to write.
The most unwanted features
The respondents were not actively downvoting features. 40% said that they don’t have issues with any of the nominated features being implemented. Other choices were distributed as follows. Top 3:
- Overloadable bitwise operators like I and & 10%
- Package-private visibility 7%
- Lateinit for nullable and primitive types 6%
Demography
71% of the respondents have 2+ years of experience with Kotlin.
85% use Kotlin in production code
You can also take a look at the types of software developed by the respondents.
Conclusion and status update by Roman Elizarov
Virtually all of the features that received the most votes are in various stages of research in the Kotlin team.
- Multicatch and Union types (KT-13108) are the most popular potential addition to the language, but this is also the most complex one to integrate into the language. Its implementation will require the combined work of many experts on the core compiler team, so don’t expect us to make a lot of progress while the team is busy getting the K2 compiler frontend to production. But once that has been released, we’ll start actively working on union types.
- Collection literals (KT-43871) have not made it into our current public roadmap but we’ve actually started some early prototyping to see what design approaches will play out well.
- Multiple receivers (KT-10468) are really close to becoming available for preview. Soon, you’ll be able to play with them using a pre-release compiler switch. Stay tuned!
- Name-based destructuring (KT-19627) has some quite controversial syntax choices, so we are in the process of planning a UX study on various syntax options to see which of them are going to be more easily understood by Kotlin developers.
- Having “public” and ”private” property types (KT-14663) turned out to be relatively easy to implement in the architecture of the new K2 compiler frontend and will be available for preview with the new compiler.
- Package private visibility (KT-29227) has received a lot of love but it also took second place for “most unwanted”. It has multiple design options and some of them have the potential to make the language harder to learn, due to novice developers having to grapple with more choices. We are taking this seriously and, just like with the original approach to designing Kotlin visibilities, we are currently studying the actual data on how Kotlin developers are structuring their codebases and what kind of solution, with what kind of default, would retain the spirit of Kotlin: defaults that allow you to get started easily while still providing the ability to tweak and customize as your project becomes more complex.
Subscribe to Kotlin Blog updates
