Answering the Top 10 Questions About Kotlin’s Future

In this post you’ll find the answers to 10 of the most upvoted questions about Kotlin’s future. You can also jump into the discussions in the comments or on Reddit (links below)!

A couple of weeks ago, as part of the 1.5.0 release event, we hosted a Kotlin team AMA on Reddit. It was exciting to receive hundreds of questions from all of you, and it was also great fun to answer them and participate in all the discussions.

When going through the questions on Reddit, we felt it was important to share them more widely. The answers are a great source of knowledge for everyone in the Kotlin community. Thanks a lot to everyone who asked the questions and to the team who carefully answered all of them. 

We received quite a few technical questions, as well as questions about the recent release. But upvoted questions, and in fact the ones we found most interesting ourselves, were about Kotlin’s future.

Questions

Question #1
Some years ago, there was a developer survey letting us vote for our most-wished features. Will there be something similar in the future? 

“Yes, at the moment we are working on the next edition of this survey. Stay tuned!” 
The thread on Reddit

Question #2 
Over the medium to long run, lets say 5 years or so, given the pace of change for Java has picked up do you envisage any problems in maintaining the compatibility of Java and Kotlin? For example are there currently any projects for changing the Java language or JVM bytecode structure which could be really difficult to integrate Kotlin with? 

“We closely follow the JVM design process, and we don’t see ourselves running into problems with any JVM features that are in development, or even with the ones that are planned for the far future.” 
The thread on Reddit

Question #3 
I asked this last time but what’s your current thinking regarding pattern matching?
 

“We are keeping it on our radar, but we feel that the most important short-term improvement that we can make to Kotlin when expressions is adding support for guards. See https://youtrack.jetbrains.com/issue/KT-13626”. 
The thread on Reddit

Question #4 
Will there be a way for Kotlin to compile to Swift instead of Obj-C for KMM? 

“Kotlin is not actually compiled to Objective-C for iOS.

Instead, at its core, Kotlin/Native compiles Kotlin directly to the native code (with the help of LLVM).

On top of that, it generates bridges to make the compiled Kotlin code accessible from Objective-C and Swift. For a Kotlin class Foo, the compiler additionally generates an “adapter” that Objective-C and Swift perceive as an Objective-C class. This adapter delegates everything to the original Kotlin class.

So, it’s more like the Kotlin/Native compiler adds an Objective-C representation for the Kotlin API. The question really is: will there be a way for Kotlin to add a Swift representation? And the answer is: this is on our radar.” 
Read more on Reddit

Question #5
Are there plans to extract the formatting feature from Intellij [IntelliJ IDEA] into a separate tool? 

“We are close to finishing our work on a formatting rules checker that will run on CI. It will be based on Qodana and launch an inspection that IntelliJ IDEA now has for Kotlin.

Currently:

  • This inspection relies too heavily on IntelliJ IDEA’s formatting settings that are stored in the .idea folder.
  • It’s not currently very informative – it just says that formatting is wrong.

We’ll hopefully address these two issues and add the inspection to Qodana.” 
Read more on Reddit

Question #6 
Previously you announced that compilation speed would be the top priority for the Kotlin team, but that it would be a multi-year effort spanning several releases. Any updates you can share on how things are shaping up?

“Our  work on compilation performance is split into two parts:

  1. Writing a new compiler frontend, with the main goal being much better performance than the existing one.
  2. Optimizing the new compiler backend (backend IR) once it is released and the most critical bugs are fixed.

The JVM/IR backend was released in Kotlin 1.5, so our JVM team will be focusing on its performance in the near future.

Meanwhile, the new frontend is actively being developed, and we want to release an early version this fall. The new compiler frontend will provide the main performance boost. At the moment, it is 4 times faster than the current frontend, which effectively doubles the speed of the full compilation pipeline (frontend + backend).

Also, since the Kotlin IDE plugin uses a compiler plugin for analysis, a new plugin based on FIR will give a performance boost for the IDE experience, too.” 
The thread on Reddit

Question #7 
Are there any plans to offer a Kotlin DI [Dependency Injection] solution natively?
 

“We feel that DI [Dependency Injection] works better as a separate library, as it makes too many competing demands for it to ever be integrated into the language or even into its standard library.”
Read more on Reddit

Question #8 
How does the idea of a Kotlin / TypeScript cross compiler sound to the Kotlin team? Similar to how Kotlin and Java can be compiled together.

“We definitely agree it would be great to have such seamless interop with JS/TS, but it’s challenging for the following reasons:

  • Kotlin and TS/JS Type systems and semantic incompatibilities.
  • TS evolves very quickly.
  • We would need to somehow integrate in both directions(!): a TS compiler written in TS and targeting the JS VM as a run environment, and a Kotlin compiler written in Kotlin and Java and targeting the JVM as a run environment. Alternatively, we could write and support our own TS compiler frontend 🙂
    (For Java it’s much simpler – we just reuse IntelliJ’s Java compiler frontend)

So, for now we are focused on a separate multistage interop – consuming TS declarations (d.ts) by converting them to Kotlin declarations and then generating TS declarations (d.ts) from Kotlin. These Kotlin-generated TS declarations (d.ts) are only available inside the new JS IR compiler backend.

Who knows, maybe someday it also will be seamless, as we’d all like ;)” 
Read more on Reddit

Question #9
What’s next for Kotlin and Spring, specifically from server side Kotlin? 

“Spring Boot 2.5 has just been released with a Kotlin 1.5 baseline and the upgraded Coroutines 1.5 and Serialization 1.2 libraries.

Our next steps are providing great Kotlin/JVM/Native (Native with Kotlin/JVM via GraalVM native images) support via https://github.com/spring-projects-experimental/spring-native/, empowering multiplatform development (with the Kotlin/JS frontend for example), translating Spring Boot documentation to Kotlin (via a contribution from the Kotlin team), and making sure that some APIs that are currently broken with Kotlin due to some type-inference bugs with recursive generic types (like WebTestClient) become usable.

Longer term, my favorite topics are getting rid of kotlin-reflect at runtime in Spring Framework by performing Kotlin reflection ahead of time, and continuing to mature https://github.com/spring-projects-experimental/spring-fu for a more DSL-ish way of configuring Spring Boot.

Even if it’s not a Spring based implementation, we would like to help https://github.com/rsocket/rsocket-kotlin, which is a great Kotlin multiplatform implementation of the RSocket protocol (https://rsocket.io/ can be an alternative to GRPC in a lot of use cases) mature.”
Read more on Reddit

Question #10 
It was planned to provide meta programming capabilities – any news on this topic?

“We’re working on meta-programming on two fronts:

More helpful resources about Kotlin and its future 

Subscribe to our Twitter, blog updates, and YouTube channel for future announcements. Soon we will launch the vote for new features in Kotlin, and we’re looking forward to hearing your take on what we should prioritize!