Simplification instead of piling up, clarifying and redoing right, as understanding grows, instead of adding extensions (like crippled lambdas to Java) and reduction to closest approximation to the [unattainable] optimum (smallest possible, well balanced set of mutually complementing each other features, like in R5RS) in general - is the right way.
I hope Swift will eventually stop piling up features and will try to get back to the right fundamentals too.)
Yes, it's like they reinvent all the things that were considered but discarded in Scala and believe they found something nobody ever thought about before.
I am not sure that Kotlin competes with Scala in any way. They are trying to remove the pain from Java by providing a concise and safe language (see the quotes from their website below). What are "all the things" they reinvented that were discard in Scala?
> Kotlin is a pragmatic programming language for JVM and Android that combines OO and functional features and is focused on interoperability, safety, clarity and tooling support.
> Being a general-purpose language, Kotlin works everywhere where Java works: server-side applications, mobile applications (Android), desktop applications.
> What are "all the things" they reinvented that were discard in Scala?
Extension methods, properties, special syntax for everything, final by default, short constructor syntax, trying to put band-aid around Java's broken collection types, ...
The pattern of throwing exceptions for operations deemed "unsupported", an API that requires massive workarounds to keep alive in Java 10, no support for immutable collections, unmodifiable views are a complete clusterfuck, no persistent collections etc.
"Android Studio should currently not be used for development with sbt and Scala. Chances are, however, that it's a good fit for a Gradle + Scala setup."
Using InteliJ instead of Android Studio means not being able to use the latest tooling even from the stable version, as InteliJ is always some versions behind.
Using Gradle + Scala implies a few configuration steps that tend to break at each new Android Studio release, versus the out of the box experience from Kotlin.
I would do more things in Ceylon if it wasn't plagued by performance problems. So far the only way I've found is to avoid any of the few libraries written in Ceylon and just use Java libraries but if you're going to do that then Kotlin's interop is far more appealing.
I hope Swift will eventually stop piling up features and will try to get back to the right fundamentals too.)