* Top level declarations

* Sealed classes

* Coroutines (in Java this is currenty only possible with Bytecode manipulation)

* Inlined Functions and Reified Generics

* Covariant Collections

* Tail Recursion

It's implemented with some bytecode hackery and hence limited to inlined functions [0], which makes it significantly less useful.

Funny how a misguided design decision from the Java 1.5 days (running generic 1.6 code with a 1.5 jre) still haunts us today...

[0] https://kotlinlang.org/docs/reference/inline-functions.html#...

What of these would you call "more expressive"? I'd agree with sealed classes, they express a limited set of possible classes. Perhaps tail recursion as I can express problems in way of recursion without stack overflows. I don't think coroutines are more expressive than Futures/get, only a runtime optimization for many concurrent executions.

callbacks -> futures/promises -> coroutines

Because callbacks are a completely different style of code, your async looks totally different. Futures and promises are better, but still make it difficult to ever break out of the async context, coroutines make the difference between async and normal code nonexistant, and allow clean escape from an async context.

Interesting. I thought the lack of proper tail recursion is a JVM limitation. Hence why Clojure uses loop/recur to handle it by translating it to a loop rather then as an actual tail call. Which means things like mutually recursive functions are not possible in Clojure without blowing the stack.

How does Kotlin handle that? Is it internally rewriting to a loop or trampoline, or did they find some way to actually make proper tail calls?

Yes. You add a `tailrec` modifier to your function. The compiler then checks if the last op in the function is a call to itself. If it is, it gets replaced with a loop. If not, you get a warning that `tailrec` is ignored.

Little things that are a apin in Java and elsewhere are quick and natural in Kotlin:

- nullable types are smoother than Options - null checks are relatively painless - the stdlib works with you, not against - named parameters and optional parameters means no need for builders - etc. Etc.

"nullable types are smoother than Options - null checks are relatively painless"

Might be the case, but Options are more expressive in that I can combine them and restrict them with other type classes to express larger constraints. Reusabilty is higher e.g. with Monad transformers like OptionT.

So nullable types are less code, but also less expressive as building blocks of larger constructs.

They might be also less expressive because they conflate two concepts: Not initialized and not-there, whereas Option expresses not-there and _ (in Scala) expresses not-initialized.

"named parameters and optional parameters"

Not sure how this more expressive?