A number of valid points, but I'm not convinced by most of your critique of Kotlin. Colon between names and types (as in "i: Int") "makes work in Kotlin harder

A number of valid points, but I'm not convinced by most of your critique of Kotlin. Colon between names and types (as in "i: Int") "makes work in Kotlin harder"? Seriously? By as much as having to end lines with semicolons in Java? : ) I understand it's a matter of habit, but how could that possibly make anybody's work hard is beyond me "I can’t imagine a valid use case for shadowing a method argument." Arguably this would be better off causing a build-time error, like in Java. But is this such a problem in practice? Do you really keep bumping into it accidentally? Just don't use name shadowing... "In my opinion, Kotlin’s type system with all these scala-like !, ?, and !! is too complex." You've listed "all these" already :) All three of them, among which "!" isn't even something you'll ever use yourself. How is it more complex than explicit null checks? It's also trivial to implement Optional in Kotlin if you think you need it. Thats pretty much all you need: https://github.com/gojuno/koptional/blob/master/koptional/src/main/kotlin/com/gojuno/koptional/Optional.kt https://github.com/gojuno/koptional/blob/master/koptional/sr... "Why Kotlin infers from Java T to T! and not to T??" Probably because not doing that would require putting "!!" or "?" pretty much everywhere you call Java code, even code that you know for certainty won't ever return null - such as Observable.create or every single RxJava operator, for instance. Observable .fromCallable(something)!! .map(String::trim)!! .distinctUntilChanged()!! .switchMap({ searchPhrase -> handleSearch(searchPhrase, view))}!! .scan( initialState ?: DEFAULT_BLANK_STATE, { full, partial -> full + partial })!! .doOnNext { logDebug(here) { "Returning new, updated full state:\n$it" } }!! Etc. That's what it would have to look like if they made it your way. "In Java, we write the class name with .class suffix: Gson gson = new GsonBuilder().registerTypeAdapter(LocalDate.class, new LocalDateAdapter()).create(); [...] in Kotlin, you are forced to write: val gson = GsonBuilder().registerTypeAdapter(LocalDate::class.java, LocalDateAdapter()).create() Which is ugly." Seriously? :) It's pretty much identical code, with slightly less noise in Kotlin. All the difference is type inference (which you praise at the beginning), and no need for two "new" keywords in Kotlin, at the cost of having to add one ".java" after "::class". The difference is rather subtle, so I honestly fail to see why the former version passes for normal while Kotlin's is suddenly "ugly"...