I honestly don't know.
you don't. Scala produces them automatically for case classes. Kotlin will treat x.count as x.getCount() if getCount exists and count doesn't. They are mostly a side effect of the tools and not strictly required.…
Well we also used Swift way before a "stable" release came out. So maybe we're masochists.
FWIW, google adopting a second JVM languages means that Android tools will trend toward operating on bytecode and not source where applicable. They released some annotation processors for Room and their lifecycle stuff…
> 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…
> 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…
I honestly don't know.
you don't. Scala produces them automatically for case classes. Kotlin will treat x.count as x.getCount() if getCount exists and count doesn't. They are mostly a side effect of the tools and not strictly required.…
Well we also used Swift way before a "stable" release came out. So maybe we're masochists.
FWIW, google adopting a second JVM languages means that Android tools will trend toward operating on bytecode and not source where applicable. They released some annotation processors for Room and their lifecycle stuff…
> 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…
> 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…