6 ms·

While the new features look great, I still can't help but feel like there's a lot of redundancy compared to things that are already commonplace in Scala. Fast f

While the new features look great, I still can't help but feel like there's a lot of redundancy compared to things that are already commonplace in Scala. Fast forwarding 2 years, I think Kotlin will still be catching up with where Scala is today, and Scala may have migrated to Dotty / 3.0 by then. Of course, there's still plenty of room for both languages, and I'm sure Kotlin will introduce interesting innovations of its own.

byefruit 11y ago
I don't think the intention for Kotlin is to have feature parity with Scala. I feel that part of Scala's problem in every project I've been involved with is that it has too many features which means if you're not incredibly careful about specifying exactly what features should be used you end up with an unmaintainable mess.
- lmm 11y ago
  > I feel that part of Scala's problem in every project I've been involved with is that it has too many features which means if you're not incredibly careful about specifying exactly what features should be used you end up with an unmaintainable mess. Whenever I've asked people to go into the specific "too many features" in Scala it always turns out they were talking about library features, not language features. The language is powerful enough that people can write very complex libraries in it. If Kotlin ever becomes popular it will have exactly the same problem.
- acjohnson55 11y ago
  > I don't think the intention for Kotlin is to have feature parity with Scala. The funny thing is that even as people say that, every new release tends to look a step closer to Scala.
jkot 11y ago
Kotlin will be always catching up. Scala is more research oriented, Kotlin is a bit more conservative and pragmatic.
- xaduha 11y ago
  It's quite possible that in many senses Kotlin will overtake Scala. Maybe not in terms of advanced language features, but in terms of adoption, tooling.
mike_hearn 11y ago
Kotlin has things Scala doesn't, like efficient optionality in the type system, and better Java interop. These are things that the Scala guys probably aren't interested in adding, and likewise, the Kotlin guys don't want to add some things that Scala has, like implicits. So thinking of it as a one dimensional line isn't really correct. Kotlin and Scala overlap in many ways, but the ways in which they don't (and will not) define them.
- lmm 11y ago
  Scala does want efficient optionality in the type system - just not at the cost of a consistent representation of optionality. I'm sure an optimization for the common case would be very welcome. I constantly see Kotlin advocates claiming better Java interop but I don't see how; Scala already has 100% Java interop as far as I can see.
  - mike_hearn 11y ago
    Luckily JVM languages mostly interop with each other very well and the question is just convenience and efficiency. For instance, Kotlin is using the same collections library as Java. So there are no adapters or conversions needed. Scala has its own collection library instead. Scala has some constructs that can make it impossible or very difficult to call code from Java. Kotlin doesn't.
    - acjohnson55 11y ago
      Those constructs are opt-in. People who are writing library code can choose to not use them. But in practice, people writing libraries in Scala that serve the Java community export a Java-specific API.
    - lmm 11y ago
      > For instance, Kotlin is using the same collections library as Java. So there are no adapters or conversions needed. Scala has its own collection library instead. You can write Scala using the standard Java collections (or Guava immutable collections) if you like (especially if you're using a ScalaZ-heavy style where everything happens via typeclasses - just write typeclass instances for the collections you're using, and then it's easy to mix and match). For my money immutability is too important for it to be worth using the Java collections - even in Java I'll use the Guava ImmutableList etc. > Scala has some constructs that can make it impossible or very difficult to call code from Java. Kotlin doesn't. Such as? I mean, implicit parameters won't be implicit (but they couldn't be in Kotlin either), and higher-kinded types compile to raw methods for which you have to cast (but you'd have to do the same to express the same thing in Kotlin).

byefruit 11y ago

I don't think the intention for Kotlin is to have feature parity with Scala. I feel that part of Scala's problem in every project I've been involved with is that it has too many features which means if you're not incredibly careful about specifying exactly what features should be used you end up with an unmaintainable mess.

lmm 11y ago
> I feel that part of Scala's problem in every project I've been involved with is that it has too many features which means if you're not incredibly careful about specifying exactly what features should be used you end up with an unmaintainable mess. Whenever I've asked people to go into the specific "too many features" in Scala it always turns out they were talking about library features, not language features. The language is powerful enough that people can write very complex libraries in it. If Kotlin ever becomes popular it will have exactly the same problem.
acjohnson55 11y ago
> I don't think the intention for Kotlin is to have feature parity with Scala. The funny thing is that even as people say that, every new release tends to look a step closer to Scala.

jkot 11y ago

Kotlin will be always catching up. Scala is more research oriented, Kotlin is a bit more conservative and pragmatic.

xaduha 11y ago
It's quite possible that in many senses Kotlin will overtake Scala. Maybe not in terms of advanced language features, but in terms of adoption, tooling.

mike_hearn 11y ago

Kotlin has things Scala doesn't, like efficient optionality in the type system, and better Java interop. These are things that the Scala guys probably aren't interested in adding, and likewise, the Kotlin guys don't want to add some things that Scala has, like implicits. So thinking of it as a one dimensional line isn't really correct. Kotlin and Scala overlap in many ways, but the ways in which they don't (and will not) define them.

lmm 11y ago
Scala does want efficient optionality in the type system - just not at the cost of a consistent representation of optionality. I'm sure an optimization for the common case would be very welcome. I constantly see Kotlin advocates claiming better Java interop but I don't see how; Scala already has 100% Java interop as far as I can see.
- mike_hearn 11y ago
  Luckily JVM languages mostly interop with each other very well and the question is just convenience and efficiency. For instance, Kotlin is using the same collections library as Java. So there are no adapters or conversions needed. Scala has its own collection library instead. Scala has some constructs that can make it impossible or very difficult to call code from Java. Kotlin doesn't.
  - acjohnson55 11y ago
    Those constructs are opt-in. People who are writing library code can choose to not use them. But in practice, people writing libraries in Scala that serve the Java community export a Java-specific API.
  - lmm 11y ago
    > For instance, Kotlin is using the same collections library as Java. So there are no adapters or conversions needed. Scala has its own collection library instead. You can write Scala using the standard Java collections (or Guava immutable collections) if you like (especially if you're using a ScalaZ-heavy style where everything happens via typeclasses - just write typeclass instances for the collections you're using, and then it's easy to mix and match). For my money immutability is too important for it to be worth using the Java collections - even in Java I'll use the Guava ImmutableList etc. > Scala has some constructs that can make it impossible or very difficult to call code from Java. Kotlin doesn't. Such as? I mean, implicit parameters won't be implicit (but they couldn't be in Kotlin either), and higher-kinded types compile to raw methods for which you have to cast (but you'd have to do the same to express the same thing in Kotlin).