|
|
|
|
|
by lmm
3799 days ago
|
|
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. |
|
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.