6 ms·

Kotlin Post-1.0 Roadmap

90 points by belovrv 11y ago

deleted 11y ago
[deleted]
acjohnson55 11y ago
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).
ungzd 11y ago
Still no more than "coffescript for java".
- xaduha 11y ago
  Nope. Please educate yourself on the subject a bit more.
V-2 11y ago
This is awesome news. yield-return semantics was something I missed dearly. Note that we’re still in the process of estimating the effort needed to implement this feature, and we don’t know whether it would be reasonable to support it in the 1.1 timeframe or it would be postponed to a later release. :) I can already tell you: yield is probably doable, async-await will have to be postponed.
- yole 11y ago
  As the post says, yield and async/await will be based on exactly the same mechanism. Either the entire mechanism will be implemented, or it will be postponed.
  - deleted 11y ago
    [deleted]
systems 11y ago
is the plan for koltin to replace java in the development of jetbrains products if yes, then i would assume the primary objective should be performance .. but this doesnt seem to be the case and my question is, is there any jvm language which is faster than java
- deleted 11y ago
  [deleted]
- lmm 11y ago
  All JVM languages "are" the same speed, because they compile to the same bytecode. OTOH some languages make it more practical / cheaper to write higher-performance code, e.g. in Scala you can use @specialized to automatically generate unboxed special cases for generic code that you'd have to write (and keep track of) by hand in Java. But if you ask "in which JVM language is it most practical/cheapest to write feature X with performance Y?" then the biggest component of the answer is going to be how easy programming in general in that language is, not anything specific to performance. The question "how fast will a naive implementation in language X perform?" does have an answer, but it's not a question you should ever be asking - if a naive implementation in language X is faster than a naive implementation in language Y, but takes 3x as long to write as an optimised implementation in language Y that's faster than the naive implementation in language X, then language Y is the better choice.
  - gregschlom 11y ago
    They compile to the same bytecode, but some languages may have features that compile to a lot more bytecode than others. A dynamic language such as Clojure, for example, is definitely slower than Java, although they are both JVM-based, because it has to do a lot more.
    - mike_hearn 11y ago
      Kotlin relies quite heavily on bytecode level method inlining, for instance. The advantage is that it makes code written in a functional style effectively free (well, almost, unless you could gain performance from step fusion). The disadvantage is that the JVM wasn't designed for that and it messes up stack traces.
sargas 11y ago
I'm very excited for 1.0.x, type aliases and a library for concurrent programming are great news. Not to mention support for Java 7-9 bytecode generation.

90 points by belovrv 11y ago

deleted 11y ago

[deleted]

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

ungzd 11y ago

Still no more than "coffescript for java".

xaduha 11y ago
Nope. Please educate yourself on the subject a bit more.

V-2 11y ago

This is awesome news. yield-return semantics was something I missed dearly. Note that we’re still in the process of estimating the effort needed to implement this feature, and we don’t know whether it would be reasonable to support it in the 1.1 timeframe or it would be postponed to a later release. :) I can already tell you: yield is probably doable, async-await will have to be postponed.

yole 11y ago
As the post says, yield and async/await will be based on exactly the same mechanism. Either the entire mechanism will be implemented, or it will be postponed.
- deleted 11y ago
  [deleted]

systems 11y ago

is the plan for koltin to replace java in the development of jetbrains products if yes, then i would assume the primary objective should be performance .. but this doesnt seem to be the case and my question is, is there any jvm language which is faster than java

deleted 11y ago
[deleted]
lmm 11y ago
All JVM languages "are" the same speed, because they compile to the same bytecode. OTOH some languages make it more practical / cheaper to write higher-performance code, e.g. in Scala you can use @specialized to automatically generate unboxed special cases for generic code that you'd have to write (and keep track of) by hand in Java. But if you ask "in which JVM language is it most practical/cheapest to write feature X with performance Y?" then the biggest component of the answer is going to be how easy programming in general in that language is, not anything specific to performance. The question "how fast will a naive implementation in language X perform?" does have an answer, but it's not a question you should ever be asking - if a naive implementation in language X is faster than a naive implementation in language Y, but takes 3x as long to write as an optimised implementation in language Y that's faster than the naive implementation in language X, then language Y is the better choice.
- gregschlom 11y ago
  They compile to the same bytecode, but some languages may have features that compile to a lot more bytecode than others. A dynamic language such as Clojure, for example, is definitely slower than Java, although they are both JVM-based, because it has to do a lot more.
  - mike_hearn 11y ago
    Kotlin relies quite heavily on bytecode level method inlining, for instance. The advantage is that it makes code written in a functional style effectively free (well, almost, unless you could gain performance from step fusion). The disadvantage is that the JVM wasn't designed for that and it messes up stack traces.

sargas 11y ago

I'm very excited for 1.0.x, type aliases and a library for concurrent programming are great news. Not to mention support for Java 7-9 bytecode generation.