Some corrections need to be made on the Kotlin pain points. In the first point about overdoing functional programming that isn’t specific to Kotlin, so that point is invalid. Any programming languages where one can do functional programming (Go, Ruby etc) allow a Software Developer to go overboard. This can happen when overusing any feature in a programming language. Functional programming does have aspects that will result in obscure (unreadable) code, but if one sticks with the “sane” parts then it is possible to develop a maintainable code base.

With the second point about the absence of best practices in Kotlin that isn’t true. Kotlin has its own official coding conventions document which is very comprehensive, and would easily rival the Go equivalent. Most Kotlin projects use a mixed OO/Functional style. There are only three programming styles that can be used in a Kotlin project: OO, Functional, and OO/Functional.

In the third point it is mentioned that Coroutines are experimental which isn’t the case. JetBrains use the word experimental (yes very confusing) with a Kotlin feature to indicate that a feature that is ready for production use, however it hasn’t gone through a lot of testing outside JetBrains to match real world use cases. This hasn’t deterred businesses from using experimental Kotlin features (especially Coroutines) in production. By the way Coroutines will be stable in Kotlin 1.3 (expected to be released in the coming weeks — rough guesstimate).

Now about the last point with async DB access. If that capability is needed then it is best to use a reasonably mature Java or Kotlin library (eg Vert.x MySQL/PostgreSQL Client — https://vertx.io/docs/vertx-mysql-postgresql-client/kotlin/). Oracle takes way too long to develop/evolve the Java platform libraries (that places small businesses/startups at a significant disadvantage). Don’t be afraid to use a well established third party library, especially if it is significantly better than the standard one.