| Method count has nothing to do with size. Look at your own link:
Java => 16,306
Scala => 67,608 (Already in multidex territory) Proguard removes most of those methods, but you'll still need multidex for any non-proguard build like tests and debug builds. And if you do grow an app past the point of being trivial as that example is Proguard gains will not be nearly as drastic Multidex on pre-Lollipop ruins app start time, and only very specific types of apps can go to targeting minSdk 21 Predexing with Multidexing and Proguard are also slow for development for non-trivial apps. Your measure of "how long it takes to pick up a phone" is far from scientific", but to compare, not a single app non-trivial app I've worked on is so simple that installing a fully compiled APK over ADB would be less than a 5-10 second process. That would leave 0-5 seconds for the entire app to build, proguard, and predex (with multidex). Not possible. Gradle 2.2+ has the SDK download feature, and before that everyone I know was already using "sdk-manager-plugin", not even for convenience on dev machines (it's not that often that SDKs come out after all), but for CI builds. Protify is not Scala exclusive if one really wants to use it, but JRebel also has a more mature Instant Run solution. Instant Run type features are useful for very specific types of changes that I don't find to be very common anyways. The layout editor + proper use of the edit mode flag and the tools namespace can already reliably replicate half of what I see instant run and co used for, with the added benefit of having even speedier development cycles. Also: Typed resources are part of Google's databinding library, not that I know anyone who uses findViewById when we have libraries like Butterknife To me using languages other than Java for Android dev is a risk about balancing mindshare, UX, and continued support for workflows in Android. Kotlin has mind share, UX doesn't suffer, and it's gotten big enough that while Google has not come out officially and said it's supported, it's mindshare is large enough that Google knows that efforts like Jack and Jill cannot adversely affect workflows (The transformation API is great example, if projects like Realm, Dagger, and co didn't have so much mindshare I doubt it'd be much of a priority for the project). Scala on Android has a much smaller mind share and is much less proven despite it's maturity, can kill UX a lot easier because of an insanely method-expensive core library which brings in thousands of methods once you use certain features, and is has not gained enough traction to to have to work around Google's plans than with them. To me the proof is in the pudding, if there were real gains to be had with Scala it'd have more traction than it does. |
You pay for exactly the stuff you are using, just like with every other library.
Well, it works without issues here. How many apps did you develop with the SBT-Android plugin to be so damn sure about its capabilities? Perfectly possible. Used that for a while now. That only seems to be a proof that good marketing is more important than good technology.