4 ms·

Which could be considered a reason to use Kotlin instead. Scala is a more powerful footgun. You pay for the power in overengineered code, slow compile times, an

Which could be considered a reason to use Kotlin instead. Scala is a more powerful footgun. You pay for the power in overengineered code, slow compile times, and worse compatibility with other JVM languages.

pkolaczk 7y ago
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).
aliakhtar 7y ago
> overengineered code False, scala is really concise. > slow compile times A few seconds slower on average, you mean > worse compatibility with other JVM languages. Its completely backwards compatible with Java.
- sa46 7y ago
  I've inherited a large scale codebase and it's been interesting to put it mildly. I agree with GP that Scala's power lends itself to building unnecessarily complex systems. - Scala has a lot of cool, but sometimes confusing features. Implicits, companion classes, apply/unapply. - our compile times are 5-10 minutes in CI. I'm sure we can make it go faster, but it requires digging into a 500 line SBT file. - Scala seems to encourage building tangled webs of actors with Akka. I understand the benefits of actors. I think the benefits are overstated vs threads when you need less than 10k threads or so.
  - aliakhtar 7y ago
    All of what you're describing here is bad programming practices. Bad programming practices * scala's power = Incredibly bad work. If you're a good programmer who writes well engineered code, you can do that incredibly well in Scala. Good practices * Scala's power = Great productivity + really good work.
  - pkolaczk 7y ago
    Companions are in Kotlin too. Apply and unapply - I never saw this being a problem even for some new programmers switching from Python. Implicits are kinda harder to use, but this is an advanced feature meant for library writers, not application programmers. Despite their power I find them much nicer to use than c++ templates. And there is nothing comparable in Kotlin, and insufficient abstraction can sometimes lead to actually more complex code than in Scala.

pkolaczk 7y ago

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).

aliakhtar 7y ago

> overengineered code False, scala is really concise. > slow compile times A few seconds slower on average, you mean > worse compatibility with other JVM languages. Its completely backwards compatible with Java.

sa46 7y ago
I've inherited a large scale codebase and it's been interesting to put it mildly. I agree with GP that Scala's power lends itself to building unnecessarily complex systems. - Scala has a lot of cool, but sometimes confusing features. Implicits, companion classes, apply/unapply. - our compile times are 5-10 minutes in CI. I'm sure we can make it go faster, but it requires digging into a 500 line SBT file. - Scala seems to encourage building tangled webs of actors with Akka. I understand the benefits of actors. I think the benefits are overstated vs threads when you need less than 10k threads or so.
- aliakhtar 7y ago
  All of what you're describing here is bad programming practices. Bad programming practices * scala's power = Incredibly bad work. If you're a good programmer who writes well engineered code, you can do that incredibly well in Scala. Good practices * Scala's power = Great productivity + really good work.
- pkolaczk 7y ago
  Companions are in Kotlin too. Apply and unapply - I never saw this being a problem even for some new programmers switching from Python. Implicits are kinda harder to use, but this is an advanced feature meant for library writers, not application programmers. Despite their power I find them much nicer to use than c++ templates. And there is nothing comparable in Kotlin, and insufficient abstraction can sometimes lead to actually more complex code than in Scala.