Living on the edge, throwing caution to the wind, a walk on the wild side and all that, I decided to
git checkout -b and give Kotlin a try on a personal budgeting app I use and occasionally tweak. I'll probably update this as I go along:
big win: able to start adding Kotlin code to an existing Java project with a few slabs of xml in
pom.xml. Java code calling Kotlin classes in the same project and vice versa, inheritance in both directions. Brilliant.
C# features that I'm enjoying: extension methods, properties, named parameters, default parameters,
var(and even better than C#,
C# features not there, which aren't a big deal but will be really welcome if Project Valhalla delivers for the JVM: value types and better generics.
the whole primary and secondary constructor thing reminds me of my foray into Scala. I'm still ambivalent about it, but trying to be open-minded. Where it gets messy is that suddenly you don't have the cleaner, Java-typical statics-then-instance, publics-then-privates and finals-then-mutable ordering of fields at the top of your class. There's presumably an idiomatic way of doing this, I just don't know it yet. I wonder whether the C++ tendency to keep privates and consts at the bottom of the file make more sense.
top-level functions. Great idea, and why not?
sad: why not save developers the RSI and call it
sad: no unsigned types. There's a post on the Kotlin forum where Jetbrains say "yes it would be nice but it's many many months of work".
the open question for me is always the extent to which the compiler can bypass boxing to get things done. This may not matter for lots of things but for serious performance, it matters (in the same vein in which your average "use BigDecimal dammit" responders on SO rather betray the kinds of systems they don't work on).
typealiasis a nice idea, but if it was as strict as a
typedefit'd be even better.
I like the fact that Kotlin re-uses and extends the Java libraries, rather than trying to reimplement everything.