I like Kotlin too, but in which way is it "much more expressive" in your opinion? What can you express in Kotlin that you can't express in Java? Scalas type system is much more expressive than the one in Java as an example. Only thing that comes to mind in Kotlin is non-nullable references.

Most of the stuff in Kotlin looks more like less boiler plate (data classes) than "more expressive".

There are quite a few things in Kotlin which are not possible in Java

* 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

> Reified Generics

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#...

See "Brian Goetz - Stewardship: the Sobering Parts" https://www.youtube.com/watch?v=2y5Pv4yN0b0&t=3399s

I do not argue that Kotlin is a nicer and a language with more features that are useful.

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.

Async/await coroutines (C#, python, ECMAscript 7) are much nicer than futures, at least ime. I think that in terms of expressiveness of async code it goes

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.

>Tail Recursion

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?

> Is it internally rewriting to a loop

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.

It's not immediately obvious, but when you write some Kotlin you'll see.

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.

I have written some Kotlin, and perhaps it's me, but I don't see.

"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?