5 ms·

One thing I've noticed with Scala is Scala devs love rewriting everything in Scala. Now, on one hand I totally get it, rewrites are fun and when you're coming

One thing I've noticed with Scala is Scala devs love rewriting everything in Scala. Now, on one hand I totally get it, rewrites are fun and when you're coming from Java and get used to Scala you never want to write any more Java. (Especially at the time when Scala was really exciting and Java people were in Java 6-7 period.) The Scala ecosystem reflects this. There's integration with Java classes, but calling Scala code from Java is less good. There's no binary compatibility between major Scala releases. Scala has its own "simple" build tool. I'm impressed the article's author was able to build their Android app in Scala. However, I would not recommend using Scala on Android. No doubt Android is popular in part because of Java, but the entire ecosystem is so much more than the programming language. The sbt-android plugin mentioned may work, but will never have the feature set of Gradle integration. (Building Android applications is much more complicated than a regular JVM app.) . In addition, sbt-android doesn't allow you to use Android Studio, which is also a huge handicap. Compatibility is likely an issue (Scala 2.12 requires Java 8, and support for Java 8 bytecode has only been introduced in O). Compile times, memory usage, method counts, etc. are all hard problems Android developers must be aware of that are blissfully ignored by the Scala team. By the way, all of this is why Android developers love Kotlin. As it was designed for complete interoperability with Java, Android devs can migrate piecemeal. You can use the same libraries, the same build system, the same IDE. The reason why the biggest announcement at Google IO was Kotlin support was because Android devs were already using the language and seeing its benefits.

gregghz 9y ago
> sbt-android doesn't allow you to use Android Studio, which is also a huge handicap. Some of our team uses Intellij, some use Android Studio to do Android dev. Both work fine with sbt-android. > You can use the same libraries, the same build system, the same IDE. This is true of Scala as well. Granted the gradle scala plugin is not great (though it does seem much better than when I last looked at it). sbt-android-gradle lets you use gradle and sbt side by side for android apps. For a while my team used this. > The sbt-android plugin mentioned may work, but will never have the feature set of Gradle integration. I'm curious if you know of any of these features sbt-android is currently misisng. I believe some of the new Android O font stuff might not work yet. Instant Run might be the next thing to be mentioned but it's replaced really well by sbt-android-protify. > Scala 2.12 requires Java 8, and support for Java 8 bytecode has only been introduced in O This is (imo) the worst part about all of this. Even Android O isn't the full java 8 bytecode so scala 2.12 still doesn't work. > all of this is why Android developers love Kotlin Yeah, I think Kotlin is a godsend for Android. One thing I don't think I mentioned in my original post was that Scala benefits from Google's kotlin support as well. It means many tools google produces (new arch components come to mind) operate on bytecode instead of source. So they (more or less) automatically work for scala too. Certainly kotlin was thought of from the ground up as an Android language and it shows. You also mention method counts a few times. I admit this is somewhat of a problem but it's also worth pointing out that sbt-android runs proguard automatically for you during release builds. We haven't come close to 65k (with or without proguard) and 70% of our method count comes from android support libraries published by google not the standard library methods provided by scala. We also target api 21 so multi-dex is not really the headache for us that it used to be.
eeperson 9y ago
> As it was designed for complete interoperability with Java, Android devs can migrate piecemeal. You can use the same libraries, the same build system, the same IDE. This is all true for Scala as well.
- pjmlp 9y ago
  Not really, it appears to require InteliJ and cannot work with the modified version that is actually Android Studio. It also doesn't integrate with the language aware tooling from Android Studio or the Gradle versions being used on Android Studio. At least this was the situation last year.
  - eeperson 9y ago
    Really? I haven't tried setting that up but here is an example from 3 years ago of some one successfully setting up this exact combination [1]. Have things gotten worse sense then? [1] https://groups.google.com/forum/#!topic/scala-on-android/0y1VQ8t4Ojg https://groups.google.com/forum/#!topic/scala-on-android/0y1...
- cryptos 9y ago
  No, it's not. Scala can call Java easily, but not the other way around. Calling Java from Scala is awkward at best (in many cases) and sometimes impossible. Scala was never engineered with a smooth Java/Scala mixed mode in mind. The opposite is true: In Scala almost everything from Java gets reinvented sooner or later.
  - eeperson 9y ago
    This hasn't matched my experience. > Calling Java from Scala is awkward at best (in many cases) and sometimes impossible. Scala was never engineered with a smooth Java/Scala mixed mode in mind. I assume you meant calling Scala from Java here. With that in mind, writing an API that is easy to use from Java isn't that difficult. It is basically down to limiting the feature set you make use of in the interface and converting to Java collections. These are both pretty easy to do. Granted some Scala features are expressed in ways that are not easily used from Java. However, this just because Scala is significantly more expressive than Java. I'm not sure why you consider this to be a problem. > In Scala almost everything from Java gets reinvented sooner or later. I'm not sure what your point is with this. Scala wrappers for Java code are common but not because of issues with calling Java code. These are written because Scala can expose a much richer and much safer interface (again because Scala is much more expressive).

gregghz 9y ago

> sbt-android doesn't allow you to use Android Studio, which is also a huge handicap. Some of our team uses Intellij, some use Android Studio to do Android dev. Both work fine with sbt-android. > You can use the same libraries, the same build system, the same IDE. This is true of Scala as well. Granted the gradle scala plugin is not great (though it does seem much better than when I last looked at it). sbt-android-gradle lets you use gradle and sbt side by side for android apps. For a while my team used this. > The sbt-android plugin mentioned may work, but will never have the feature set of Gradle integration. I'm curious if you know of any of these features sbt-android is currently misisng. I believe some of the new Android O font stuff might not work yet. Instant Run might be the next thing to be mentioned but it's replaced really well by sbt-android-protify. > Scala 2.12 requires Java 8, and support for Java 8 bytecode has only been introduced in O This is (imo) the worst part about all of this. Even Android O isn't the full java 8 bytecode so scala 2.12 still doesn't work. > all of this is why Android developers love Kotlin Yeah, I think Kotlin is a godsend for Android. One thing I don't think I mentioned in my original post was that Scala benefits from Google's kotlin support as well. It means many tools google produces (new arch components come to mind) operate on bytecode instead of source. So they (more or less) automatically work for scala too. Certainly kotlin was thought of from the ground up as an Android language and it shows. You also mention method counts a few times. I admit this is somewhat of a problem but it's also worth pointing out that sbt-android runs proguard automatically for you during release builds. We haven't come close to 65k (with or without proguard) and 70% of our method count comes from android support libraries published by google not the standard library methods provided by scala. We also target api 21 so multi-dex is not really the headache for us that it used to be.

eeperson 9y ago

> As it was designed for complete interoperability with Java, Android devs can migrate piecemeal. You can use the same libraries, the same build system, the same IDE. This is all true for Scala as well.

pjmlp 9y ago
Not really, it appears to require InteliJ and cannot work with the modified version that is actually Android Studio. It also doesn't integrate with the language aware tooling from Android Studio or the Gradle versions being used on Android Studio. At least this was the situation last year.
- eeperson 9y ago
  Really? I haven't tried setting that up but here is an example from 3 years ago of some one successfully setting up this exact combination [1]. Have things gotten worse sense then? [1] https://groups.google.com/forum/#!topic/scala-on-android/0y1VQ8t4Ojg https://groups.google.com/forum/#!topic/scala-on-android/0y1...
cryptos 9y ago
No, it's not. Scala can call Java easily, but not the other way around. Calling Java from Scala is awkward at best (in many cases) and sometimes impossible. Scala was never engineered with a smooth Java/Scala mixed mode in mind. The opposite is true: In Scala almost everything from Java gets reinvented sooner or later.
- eeperson 9y ago
  This hasn't matched my experience. > Calling Java from Scala is awkward at best (in many cases) and sometimes impossible. Scala was never engineered with a smooth Java/Scala mixed mode in mind. I assume you meant calling Scala from Java here. With that in mind, writing an API that is easy to use from Java isn't that difficult. It is basically down to limiting the feature set you make use of in the interface and converting to Java collections. These are both pretty easy to do. Granted some Scala features are expressed in ways that are not easily used from Java. However, this just because Scala is significantly more expressive than Java. I'm not sure why you consider this to be a problem. > In Scala almost everything from Java gets reinvented sooner or later. I'm not sure what your point is with this. Scala wrappers for Java code are common but not because of issues with calling Java code. These are written because Scala can expose a much richer and much safer interface (again because Scala is much more expressive).