[vbezhenar]

I spent literally one evening reading Kotlin reference and I understood an entire language. It's just a Java with slightly altered syntax and a lot of simple yet useful batteries included. I immediately was able to start coding and reading standard library. On the other side in the past I spent around week reading book about Scala. Yet I couldn't read Scala library, it was just too complex. So I don't agree that their complexities are even comparable.

Scala is like a Haskell. It's very powerfull, but to understand and use the entire language, one should make a serious investment.

[lmm]

That's because Kotlin puts the complexity in the language and Scala puts it in the libraries. A lot of things are just a rule of the language in Kotlin but they're implemented in ordinary code in Scala. E.g. extension methods. Which means you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure.

[evacchi]

> you can "understand" them quicker in Kotlin, but you can't change how they work or use them to implement a new structure.

I'm not sure that extension methods are a particularly fitting example here.

Scala adds a lot of boilerplate for — in my view — very little gain. Of course, Scala's extension methods are actually a special case for implicit conversions; yet, the Scala we write today in my experience tends to avoid implicit conversions per se.

E.g., I'd rather be explicit about a type conversion when that is what I want to achieve: for instance, I'd rather read `javaListMethod(mySeq.asJava)` than `javaListMethod(mySeq.asJava)`. Thus, I'd rather have a first-class construct for extension methods rather than having to write `implicit class RichSeq(val s: Seq) extends AnyVal { def asJava = ... }`

In this case I do prefer Kotlin.

[lmm]

Boilerplate is a problem but doesn't make a language harder to understand. Language-level shortcuts to reduce boilerplate generally make the language harder to understand, IME (I'm thinking of e.g. Perl's $_).

I actually agree that implicit conversions are to be minimized. But you do need a way of doing the equivalent of the magnet pattern - which in Kotlin is either a different language-level feature, or simply impossible. I'm hopeful that a simpler underlying abstraction can be found - but Kotlin feels to me like it's just piling on a bunch of special cases without making any effort to be consistent or unified.

[evacchi]

You won't be able to implement type classes. There might be something in that direction after 1.0; still, Kotlin is not supposed to be a contender with Scala w.r.t. expressive power. It is just Java with more concise syntax, and with most design patterns turned into language features: singleton, delegates, lambdas/sam, "utils" classes (extension methods).