6 ms·

I think the main differences Scala being much more of a functional programming language where as Kotlin is a bit of a balance between Java/OOP and FP and affect

by osdev 5y ago

I think the main differences Scala being much more of a functional programming language where as Kotlin is a bit of a balance between Java/OOP and FP and affects the complexity/learning curve of the respective languages. OVERVIEW - Scala is much more of a functional programming language - Scala has a steeper learning curve - Scala community/ecosystem leans much more towards FP - Kotlin is like Functional Programming "lite" LANGUAGE - Scala: has higher kinded types - Scala: has for comprehensions - Scala: has type classes - Scala: has built in support for monads - Scala: has better support for encoding errors at compile time MARKET - Kotlin: has heavy usage on Android - Kotlin: on the server side is pretty active too - Kotlin: integrates nicely with java - Kotlin: multi-platform support

karmakaze 5y ago
Choosing Scala with the intent of only using the simpler parts isn't a path I've seen work out. Maybe with strong dev culture, documentation, and tooling that could work. My experience has been that you end up with more complex implementations than you wish you had to maintain. The other way to go is to hire for it--so everyone is competent and comfortable with that level, at which point it's typically not the subset. With that view I would only suggest Scala over say F# or OCaml if JVM compatibility was a requirement.
- esarbe 5y ago
  It's fine, actually. I've been working many teams over the last eight years using Scala. The important thing is to know where you _don't_ want to go and you'll be fine. Clean code is a developer's agreement. > My experience has been that you end up with more complex implementations than you wish you had to maintain. Don't you get that with any language? I for one always find myself in a battle against complexity, no matter the language.
  - karmakaze 5y ago
    There is a difference. The advanced Scala one may be simpler in concept if the high level concepts/idioms are known and a complete mystery if not. With less expressive languages the complexity is due to the volume rather than nature of code if that makes it any clearer. Metaprogramming or code generation is similar. You can certainly make smaller, more sophisticated solutions with it. I would consider that has a comprehensibility cost and need some justification for its use, if not merely for academic/learning purposes. Maintainability could go either way depending on the situation and team composition.

by osdev 5y ago

karmakaze 5y ago

Choosing Scala with the intent of only using the simpler parts isn't a path I've seen work out. Maybe with strong dev culture, documentation, and tooling that could work. My experience has been that you end up with more complex implementations than you wish you had to maintain. The other way to go is to hire for it--so everyone is competent and comfortable with that level, at which point it's typically not the subset. With that view I would only suggest Scala over say F# or OCaml if JVM compatibility was a requirement.

esarbe 5y ago
It's fine, actually. I've been working many teams over the last eight years using Scala. The important thing is to know where you _don't_ want to go and you'll be fine. Clean code is a developer's agreement. > My experience has been that you end up with more complex implementations than you wish you had to maintain. Don't you get that with any language? I for one always find myself in a battle against complexity, no matter the language.
- karmakaze 5y ago
  There is a difference. The advanced Scala one may be simpler in concept if the high level concepts/idioms are known and a complete mystery if not. With less expressive languages the complexity is due to the volume rather than nature of code if that makes it any clearer. Metaprogramming or code generation is similar. You can certainly make smaller, more sophisticated solutions with it. I would consider that has a comprehensibility cost and need some justification for its use, if not merely for academic/learning purposes. Maintainability could go either way depending on the situation and team composition.