I have mixed feelings about kotlin, I read that same book, kicked tires and all. On paper it does look nice, but it seems most of the ecosystem is just java in kotlin style code even tho there could be a more functional approach given what it can do. Maybe this will change, or maybe java will catch up (hopefully in our lifetime) with some of the features/syntax introduced by kotlin, but atm the moment it has too much of a "coffeescript for java" after taste to me.

clojure still is the better option on the jvm 🙂 unless you have to work with android I guess

@mpenet "coffeescript for java" -- interesting observation. I've gotten further through the Kotlin web site now and covered interfaces and classes and that all seems to be a bit of a mess to me. So many options and so much syntax -- and not much idiomatic guidance on how best to structure things. Definitely more flexible than Java in that area but not much cleaner. Maybe I just find OOP rather ugly these days in any form...?

If you have to do raw Java, Kotlin's an easier stepping stone to sell to a team than leaping into Clojure, and might get them used to some of the benefits of functional programming. The interop between Java and Kotlin and the easy drop-in drop-out between Kotlin files and Java files also help the story. That said, it does often feel like it makes too many utility functions that have useful mechanics that are difficult to keep separate in your mind: let, apply, with, and run, for example, have different semantics. https://medium.com/@tpolansk/the-difference-between-kotlins-functions-let-apply-with-run-and-else-ca51a4c696b8

Having 'case classes' and 'data classes' circumvents some of the more annoyingly verbose Java boilerplate, and usually serves as the gateway drug from the anecdotes I've heard.

Personally, not having to keep 'file-per-class' sells me big-time, oddly enough, as do locally-scoped extension methods for writing locally-tidy code.