4 ms·

Scala compatibility with JVM is the same as Kotlin's. It is implemented the same way in both languages - they compile to JVM bytecode and as long as you keep aw

Scala compatibility with JVM is the same as Kotlin's. It is implemented the same way in both languages - they compile to JVM bytecode and as long as you keep away from non-Java features, interoperability is good both ways. If you start using stuff not directly supported by Java like default arguments or multiple inheritance of traits, then calling Scala/Kotlin code from Java is similarly bad experience. Scala has also a few more non-Java features e.g. macros or implicits, so I get how you could end up with this impression. Just don't use these features of you need to call your code from Java. As for compile times, Scala with Bloop is the fastest of JVM languages I ever saw. We switched to compile Java with Bloop because it is orders of magnitude faster than Maven/Gradle. Bloop works for Java and Scala, but not Kotlin. So Kotlin, having really nothing comparable at the moment, is currently the slowest to compile from these three languages.

izolate 7y ago
Something doesn't add up. First you say (emphasis mine): > Scala compatibility with JVM is the SAME as Kotlin's. Then you follow up with: > Scala has also a few more non-Java features These are contradictory claims. OP had a very good point about Scala being a more powerful footgun. Unfortunately, consciously avoiding features is not a matter of "just", and rarely works out in practicality.
- pkolaczk 7y ago
  No they aren't contradictory. What is the compatibility of a feature that even doesn't exist in Kotlin? How can be the lack of way to call a Scala macro from Java a disadvantage, when Kotlin doesn't allow you to call a macro from neither Java nor Kotlin, because this feature doesn't exist? Scala is strictly superior in this case. And you need to avoid some features only in code that gets called from Java, not the whole codebase. Calling it this direction is very rare and not really a problem. Most codebases call Java from Scala and this is easy and fully supported.
  - AlphaSite 7y ago
    100 intercompatiblity is a feature.
    - pkolaczk 7y ago
      But Kotlin doesn't have 100% interoperability! There are features in Kotlin which don't map nicely to Java features. For example you can't call methods with default arguments from Java without resorting to unreadable hacks relying on a way defaults are implemented (same is true for Scala).

izolate 7y ago

Something doesn't add up. First you say (emphasis mine): > Scala compatibility with JVM is the SAME as Kotlin's. Then you follow up with: > Scala has also a few more non-Java features These are contradictory claims. OP had a very good point about Scala being a more powerful footgun. Unfortunately, consciously avoiding features is not a matter of "just", and rarely works out in practicality.

pkolaczk 7y ago
No they aren't contradictory. What is the compatibility of a feature that even doesn't exist in Kotlin? How can be the lack of way to call a Scala macro from Java a disadvantage, when Kotlin doesn't allow you to call a macro from neither Java nor Kotlin, because this feature doesn't exist? Scala is strictly superior in this case. And you need to avoid some features only in code that gets called from Java, not the whole codebase. Calling it this direction is very rare and not really a problem. Most codebases call Java from Scala and this is easy and fully supported.
- AlphaSite 7y ago
  100 intercompatiblity is a feature.
  - pkolaczk 7y ago
    But Kotlin doesn't have 100% interoperability! There are features in Kotlin which don't map nicely to Java features. For example you can't call methods with default arguments from Java without resorting to unreadable hacks relying on a way defaults are implemented (same is true for Scala).