Nothing in life is perfect, and alas, neither is Kotlin. Here are some of the issues I experienced whilst trying out the language.

The biggest problem is immaturity. Kotlin is a pre 1.0 language. This means:

• The language, ABI and standard library change in every release. The good news is the changes tend to be small and IntelliJ can often upgrade your code for you. So this is less painful than it sounds.
• The Java-to-Kotlin converter (J2K) isn’t finished. It occasionally mangles formatting and silently erases Java 8 lambdas (edit Oct 2015: as of M13 the converter now handles Java 8 features correctly). And the code it produces isn’t always the best way to write things. But JetBrains are putting significant effort into this tool, and it’s already the best of its kind I’ve ever used. So I don’t worry about this too much: it is getting better rapidly.
• You will encounter compiler bugs. My programs are not large, yet I routinely encounter code that should compile but doesn’t, or (worse) code that silently compiles to the wrong thing. Diagnosing these issues is not too difficult, but it adds friction to the experience. (edit: as of 1.0 beta 3 I am using Kotlin every day and did not encounter any compiler bugs for a while now: this situation has improved a lot in the 5 months since the article was written)
• You will encounter internal IDE errors. When this happens you get a little floating bubble and an option to report it to JetBrains. The IDE doesn’t close and most of the errors seem to be survivable without problems. Regardless, this can be annoying.
• The documentation occasionally refers to features that aren’t implemented (edit: as of M14 this is no longer an issue)

I expect these issues to fade away now JetBrains is focusing on shipping 1.0 rather than adding new features.

The second biggest problem I’ve had is that sometimes the requirements of Java interop result in unintuitive limitations.

A classic bug the Java type system fails to protect you against is changing the key type of a map. It is reasonable to expect that this will cause compile errors if you try to, for example, remove a key of the wrong type. But when the JDK collections were generified, they left the parameters of some important methods as Object, so the compiler won’t complain. When editing Java IntelliJ can flag these cases via yellow static analysis warnings, but so far the Kotlin editor doesn’t. Because Kotlin doesn’t define its own collections library either, this results in a compromise of type safety which has now bitten me several times.

(edit: as of 1.0 beta this problem has now been resolved, and the remaining lack of type safety in the Java collections framework is fixed when using it from Kotlin)

As another example, when calling into or using Java code, the null safety Kotlin gives you is disabled for those calls (it can be brought back using annotations). Because much of the code you will write as a Kotlin beginner is simply calling into Java libraries the feature ends up being less useful than you might hope. It only comes into its own later, as the amount of Kotlin you have grows. JetBrains have seesawed around on how to combine null safety and Java interop: their current approach is good, but sometimes fails to catch errors. They want to tighten null safety and Java interop when it’s safe to do so. (edit: as of M13 they are now using Java @NotNull annotations when safe to do so)

The flip side of all this is that you get much smoother usage of Java APIs, and I find the tradeoff to be worth it. But it’s something to be aware of.

Other issues to consider:

• The community is small. Whilst the excellent Java interop means you don’t really need Kotlin libraries, they’re still nice to have and currently there aren’t many.
• If you like learning by reading a book you’ll have to wait until later this year when Manning will publish one. Until then it’s the website or nothing.
• FP purists may feel the type system is lacking some of the more advanced features that can be found in Scala or Haskell. If you’re the sort of person who cares about type systems more than average, Kotlin may not be for you. (edit: the funKTionale library adds some constructs known from Haskell to the language)
• Whilst it can compile down to JavaScript, this mode appears to be less well used than the JVM backend and you may encounter more issues, though note I don’t have any experience with it, this is just my impression from reading the forums. (edit: the JS backend has been deprioritised in order to launch Kotlin 1.0 faster, and JetBrains will go back to work on it once the language is stable on the JVM)
• There is no standard style guide, and at points Kotlin gives you several alternative syntaxes to choose from. Kotlin written by different people may look different. This is in contrast to Go, which enforces style rigidly.
  (edit: as of Kotlin 1.0 some of the syntax flexibility has been removed, e.g. now operator and infix functions must be explicitly marked)
• Kotlin compiles a bit slower than Java, and the IntelliJ editor is slightly more sluggish. But not seriously so, and both are much faster than for Scala.
  (edit: as of Kotlin 1.0 beta compilation times have improved by several multiples and there is no longer any difference in IDE responsiveness)
• There is an Eclipse plugin for Kotlin, but it is naturally much less sophisticated than the IntelliJ support. Kotlin will work best if your team standardises on IntelliJ.
• Kotlin is pickier about some things than Java. It will not autoconvert integers to longs and such, you are required to specify you want the conversion explicitly. This is because the language has a focus on correctness and attempts to fix the issues found in the famous “Java Puzzlers” book. JetBrains claim they nailed about half of them.
• Because Kotlin targets Java 6 it is restricted to the features that runtime has. Whilst it can match or exceed C# in many areas, it lacks features like value types which aren’t yet a part of the Java platform.