Personally I think a good way to set a foot in the door (with Kotlin) is to use it for unit tests. Hey, unit tests aren't production code, so what's the worst t

Personally I think a good way to set a foot in the door (with Kotlin) is to use it for unit tests. Hey, unit tests aren't production code, so what's the worst that can happen, right? Plus in many projects - sadly - tests are still perceived as an optional thing. And Kotlin is very well suited for tests, because it's so expressive, DSL-friendly etc. There's also this pleasant framework: http://jetbrains.github.io/spek/ http://jetbrains.github.io/spek/ If you can't convince your team (or bosses) to switch to Kotlin, start writing unit tests in Kotlin. They can even coexist with Java ones, so I believe this is an easy way in. And once people get to see it at work...