4 ms·

> compilation times, to method counts, to binary sizes, to performance besides compile times (mitigated almost entirely by incremental compilation) none of the

> compilation times, to method counts, to binary sizes, to performance besides compile times (mitigated almost entirely by incremental compilation) none of these things hold up. Method counts are irrelevant with proguard and multi-dex (FWIW, most of our count comes from google support libraries anyway). Our binary is around ~5mb. I haven't ran benchmarks but I promise you that http requests, writing to disk, and WebView performance aren't slower because of Scala.

BoorishBears 9y ago
So you're saying the app is so small and extremely simple that even at full load jank isn't an issue, that multidex and size aren't an issue because you're not forced to focus on startup times and there are hardly any assets. And I'm not saying that skeptically, I really believe it. Which is all the more reason that I don't see why you'd go with the using Scala. I don't know if you're referring to Lucidchart but I just look at that app and I can definitely see how it might not have to worry about jumping through hoops to shave startup time from a high method count or loading large data sets with tons of serialization and performant animations where built in immutable collections have unacceptable GC implications. On the other hand you can apply that same reasoning and say it doesn't matter that Scala was used. But then you wonder why the "case study" should be considered by others, who probably don't have the luxury of having a small minimally animated app that can ignore stuff like method count effects on startup speed. To me the things that separate a top 50% app from a top 1% are things like high method counts affecting startup time on slower devices. It's not like Kotlin doesn't have issues that mirror those in Scala, but because it's essentially a "thin wrapper Java" with a slim standard library it's easy enough to identify when you're going to run up against parts with those performance implications
deleted 9y ago
[deleted]

BoorishBears 9y ago

So you're saying the app is so small and extremely simple that even at full load jank isn't an issue, that multidex and size aren't an issue because you're not forced to focus on startup times and there are hardly any assets. And I'm not saying that skeptically, I really believe it. Which is all the more reason that I don't see why you'd go with the using Scala. I don't know if you're referring to Lucidchart but I just look at that app and I can definitely see how it might not have to worry about jumping through hoops to shave startup time from a high method count or loading large data sets with tons of serialization and performant animations where built in immutable collections have unacceptable GC implications. On the other hand you can apply that same reasoning and say it doesn't matter that Scala was used. But then you wonder why the "case study" should be considered by others, who probably don't have the luxury of having a small minimally animated app that can ignore stuff like method count effects on startup speed. To me the things that separate a top 50% app from a top 1% are things like high method counts affecting startup time on slower devices. It's not like Kotlin doesn't have issues that mirror those in Scala, but because it's essentially a "thin wrapper Java" with a slim standard library it's easy enough to identify when you're going to run up against parts with those performance implications

deleted 9y ago

[deleted]