interesting function parameter name shadowing issue they highlight. had not run into that, but, wow, that adds some serious confusion. i also heartily agree wi

interesting function parameter name shadowing issue they highlight. had not run into that, but, wow, that adds some serious confusion. i also heartily agree with the article's points about nullable types and Java library interop: it's pretty annoying to deal with Kotlin non-nullable types that have to interoperate with existing Java libraries that have nullable types in return values or function callback parameters. i have way more question marks in my Kotlin code than i originally thought i would. i also appreciated the article's scrutiny of the name and type order reversal in Kotlin and the "::" syntax for getting the class literal (::class vs ::class.java). still trying to get used to that. and as for the learning curve, i have to admit that it's been steeper than i expected when i first saw introductory presentations. Kotlin feels very abbreviated. the smart type inference and things like 'lateinit' have sometimes surprised me in their behavior. these aspects of Kotlin are indeed very smart, sometimes too smart for me. i feel like i have to think harder to understand a piece of Kotlin code, which is ok, but somehow, i wasn't expecting that based upon the initial presentations. overall, Kotlin is ok i guess, but, to go off-topic for a sec, as an Android programmer i wondered why Google chose to emphasize adding a new language when many other aspects (e.g. documentation, the jumble of GPS, Firebase, GCM and 3rd party libs, mysterious adb failures, emulator problems, instant run, etc), of the ecosystem needed improvement/simplification/clarification more desperately.