Why Scala didn't miss the Android opportunity

By William Narmontas,

This page can be edited on GitHub.

Original article at Medium.

Kotlin and Android just tied the knot. This is a disappointment for us Scala users, but let me explain to you perhaps why it is not a disappointment to me.

I had tried out Scala and Android in 2015 and it was not fun because of countless interferences against Scala on Android there:

  1. Android (more specifically Android Studio) prefers Gradle as a build tool, which is the first interference against Scala. I cannot use my existing SBT knowledge and standard Scala ways of doing things.
  2. When I tried SBT, for which an Android plugin exists, I ran into many roadblocks as well. Usability was poor and I couldn't use any Android Gradle plugins. And SBT on IntelliJ was terribly slow whereas Gradle fast.
  3. Scala wrappers did not match any of the existing Android base of knowledge, and writing Java-like Scala did not appeal either.

Some people also complained of the large size of Scala library.

Kotlin on the other hands deals with Java's collections directly and supports enough things to make people happier, but not have to face a steep learning curve that is Scala.

You can migrate to Kotlin on Android incrementally.

Scala, unlike Kotlin, pushes JVM boundaries to create a better programming environment, whereas Kotlin fixes the immediate problem of Java being verbose. That is what most developers want, and they absolutely do not care about type classes and implicits that Scala is capable of, because they were still stuck in the dark ages of Java 6 & Android which doesn't even provide basic oxygen like Lambdas.

When Scala 2.12 came out, rightfully targeting only Java 8, Android did not support Java 8 features, and this was the nail in the coffin.

Historical reminder

As soon as Java 8 came out, people were asking whether this is going to kill Scala. It wasn't going to, and it didn't. The Java platform doesn't compete against itself, but enhances itself.

Java 8 brought native lambdas meaning Scala was able to shed some skin and compile faster and leaner. A better JVM, invokedynamic and many other goodies. Best of all, it brought functional awareness into the lives of millions of developers, who are now capable of appreciating what Scala offers.

Great potential

The same is going to happen with Kotlin. Kotlin brings a better Java, and Dalvik will provide features that make it easier to support and promote Scala in future. "Here's how you do X in Kotlin, and here's how you do Y in Scala".

With completion of Dotty (Scala 3.0), we will have a far more proven programming language that is easier to work with. It'd only be premature to promote what is not ready yet. We're in merely in a transition phase, so there is nothing to worry about.

Refocusing

There is a great lot that the Scala community can learn from this, and create a far better product in future. Now we have the data points which we did not have before.

OpenJDK is not the only way to run Scala on Android

Scala targets JavaScript (browser and Node.js) too. React Native targets Android. And brilliant developers have already built Scala React Native tooling. Scala also targets Native, and I didn't face problems in my first go at it. Seeing Scala.js mature so well, and Native having an initial painless experience, I have the confidence that in future Scala will successfully target platforms well beyond Android.

Scala and its tooling are improving at such an incredible rate. I am all-in and I am pleased to know it is heading in the right direction.

Conclusion

Scala on Android will happen, but it will happen through osmosis. Thanks to Scala's cross-platformness, scalability over Kotlin, and other FP or FP-like languages on the JVM and Android.