Kotlin Stability

1

I'd like to talk about pushing for more focus on stability in Kotlin, for the IDE, compiler, and runtime. I'd like to frame this discussion as constructively as possible, and while I may seem rather hyper critical on what is still a very young project, I hope this can drive some good discussion.

I’ve been working with Kotlin for almost a year now, working on a pretty aggressive startup concept, and occassionally on production projects for clients who can stomach work being done in an obscure language. I’ve always been a strong advocate of JetBrains IDEA; the quality, features, and usability is unmatched. Those that came to IDEA from Eclipse will never go back once they’ve passed the learning curve.

Kotlin is an elegant language. It’s one of the few options I have to develop for multiple platforms with a single codebase without resorting to embedding a browser and making a ‘hybrid’ app. Unlike competitors like TypeScript or Dart, the Kotlin language is built alongside its tooling, making the IDE support far superior.

I do feel, however, that there has been a lot of friction with Kotlin development. The JetBrains team has been fast responding to critical bug reports, but I feel like I hit friction every day using Kotlin. I feel that the benefit of an added feature doesn’t match the frustration of something not working correctly. I’d like to see Kotlin “slow down”, and really focus on product stability. This frustration I feel is fairly common when working with more obscure languages such as AS3, TypeScript, CoffeeScript, and Dart, which in turn strongly pushes me back towards the giants Java, JS, C++, and PHP.

I understand that Kotlin must have a fraction of the resources as the Java team does, and that in particular KotlinJS is still in its infancy, but I still think some extra cycles could be spent really hammering on testing the features developed before release. If JetBrains needs an enormous KotlinJS+KotlinJVM project to hammer on, I can help with that :).
To be specific about the things that I feel are less than stable, I’ve reported over 60 issues in the last year, and countless IDE fatal error stack traces. I feel like I spend at least 25% of my development time on friction points.

  • Advanced IDE features (refactor, move, organize, etc). I would rather not have a feature than to have a feature only work some of the time. It burns time trying to isolate the problem, report it, and avoid that specific scenario in the future.
  • Kotlin language behaving the same in JS as it does in JVM (supported features, differences in operation, data structure differences)
  • KotlinJS runtime bugs
  • KotlinJS compiler bugs (especially when no filename is given when the compiler crashes)

KotlinJVM has much fewer issues, but my sentiments still apply--  I want to be on the bleeding edge of technology without quite so much bleeding :)

2

I'd argue that the issues you are describing have a lot less to do with the size of the Kotlin team and everything to do with the fact that Kotlin is not 1.0.

Pre-1.0, I think the Kotlin team should feel free to break anything they feel like and whenever my code breaks (which has happened a lot over these past years), I see this more as a consequence of me using a pre-1.0 product than a fault of the Kotlin team.

Post-1.0, I will stand firmly on your side and I will hold them accountable for maintaining a very rigid backward compatibility (but I’m pretty sure they will need no reminder for this).

3

JB have been saying for a while now that their focus has shifted to finishing off the language and getting to 1.0

If you look at the commits on github there have been a lot of IDE crash fixes and refactoring bug fixes going into M13. I’m hopeful that it will be more stable than previous releases have been.

4

I will agree with you to the extent of things like API solidification, feature thrashing, even instability for a new feature. I'm not expecting Kotlin to have a formal deprecation strategy or anything like that, I want them to be agile, try things out, etc. Even post 1.0 I'd like to see them keep agility and keep supplying those awesome "refactor all like this" quick fixes to migrate large codebases to the new API. Even pre-1.0 software I strongly believe that features shouldn't be released until they're stable. For example, in KotlinJS there are a lot of problems using inline functions, so instead of letting the stalwart "beta" developers of Kotlin pre-1.0 find this out through runtime crashes, they shouldn't expose that feature until they believe it to be ready. I understand that they can't catch everything before release, but it's like popcorn, don't serve it until the kernal pops start to become far between.

5

Right now we aren't focusing on KotlinJS at all, and it will be available as an experimental feature in the 1.0 release, with no guarantees of feature completeness, stability or backwards compatibiity. We plan to resume work on KotlinJS after the JVM-targeted 1.0 release is out.