Ah, I came here to +1 the IDE comments. Not so muc...

# kotlin-roadmap

[mikehearn]

Ah, I came here to +1 the IDE comments. Not so much about features, but I'd really like to see some recognition of IDE exceptions as being a problem that could use tackling. It is something I always expected to be temporary in the early days but here we are in Kotlin 1.4 and I get IDE exceptions ~every day when on stable versions, and every few minutes when on EAP versions of either Kotlin or the IDE. Many of them are quite repetitive, but they do change over time as well, so this feels like a general issue where the IDE plugin has structural complexity issues that make it too hard to avoid bugs. I must have reported many hundreds of exceptions over the past years, perhaps over a thousand, but it's hard to notice any difference in plugin robustness.

[Anton Yalyshev [JB]]

You rightly noted that this problem is worthy of high attention. And it really is now in the Top 5 of our priorities. In fact, directly or indirectly, we are working on this in four directions:
1. Move to the new infrastructure (KT-42308). Some of the Exceptions are related to shortcomings in the integration between the plugin and the IJ platform. In the new infrastructure, such problems will either be easier to fix, or they will not appear at all.
2. We recognized the importance of the problem around 1.3.50 release. We began to devote more time to it, and the dynamics of Exceptions (according to the data of anonymous statistics) is reduced by 1.5 times per release (1.3.6, 1.3.7 ...).
3. It’s not distinguishable for a user, but some of the Exceptions that you see in the IDE actually happen in the compiler. Recently, the IDE and Compiler teams have started working together on exception reports to raise the effectiveness of fixes delivery.
4. Prototype IDE plugin with the new compiler frontend (KT-42307). I suppose you meant this task by saying “compiler rewrite”? As you rightly pointed out, some problems have been showing up for a long time. Sometimes fixing them requires tricky architectural changes and it finally leads to the accumulation of tech. debt. Rewriting plugin modules for the new compiler takes into account these accumulated old problems, and in the new implementation, many of them simply will not exist. This is something like resetting that debt.
Therefore, the issue of Exceptions and plugin stability is recognized and stays among our highest priorities. Thank you for bringing this up!

[mikehearn]

Thank you for the excellent answer Anton. I remain a big fan of JB 🙂

[Marc Knaup]

That’s roughly also what I’m experiencing. Kotlin as a language is amazing, as is the stdlib, but the tooling causes most headaches.

My primary annoyances, i.e. priorities for improvement in everyday coding:
1. IDE/Gradle integration. All too often a project works fine in Gradle but the IDE fails in various ways. Unable to resolve something. Unable to run something. Wrong dependencies. Sync fails. Subtle differences. Especially bad when mixing composite builds, multiplatform and multi-module projects.

2. IDE reliability. Exceptions occur quite often (though most are harmless), random slowdowns (though less than in the past). Also, Kotlin doesn’t require package names and directory names to be in sync. Yet refactoring frequently messes up my packages because it assumes that I want both in sync.

3. Debugging reliability. Stepping through code is still a hit-or-miss. Debugging coroutines is incredibly difficult and stack traces often useless. Line numbers are often incorrect esp. when inline code is involved. Breakpoints not working. IDE freezes. Etc.

4. Compiler exceptions & bugs. Sometimes I have to change code or even API just to work around these issues. Or code that used to work breaks after a Kotlin update due to compiler bugs. Inline classes are highly unreliable as bugs often occur in edge cases at runtime.

5. Language limitations in edge cases. Generic property delegation that I’ve used for DI was briefly possible, then gone. Not able to call functions with conditionally passing values for parameters with default values, etc (for deserialization). More flexible inline classes (e.g. private constructors).

6. Kotlin-first basic building blocks beyond the stdlib, platform-independent. Be it IO, localization, date/time, currencies/countries.

However, compared to Xcode for example IDEA is lightyears ahead 🙂
I’ve used Xcode for years and got used to it. Now I’m using mostly IDEA and whenever I have to do something in Xcode I see how far ahead IDEA is by now. Despite the current issues, it’s a really amazing IDE.

[mikehearn]

I'd actually rather they de-prioritise (6). It ends with re-creating most of the Java stdlib. Now there is native-image, you can make iOS apps with Java libs, and of course they run on Android and every other platform too. And Kotlin/Native is coming closer to the JVM with its new GC.

[Anton Yalyshev [JB]]

Thank you guys for this general view of priorities - it’s handy for our planning sessions. Regarding Gradle integration and Debugger experience - these areas stay a little bit behind the performance and overall plugin stability tasks but will go next.

[Marc Knaup]

Thank you for your continuous effort. I can imagine how big of a challenge this must be given all the complexity. Nonetheless you're making great progress 👍