Kotlin Post-1.0 Roadmap • Hacker News Board

Re: Kotlin Post-1.0 Roadmap

#31

Post by merb » Thu, Apr 14, 2016, 7:47 PM UTC

ta_donk_gt wrote: post #30

lmm wrote: post #8

Earlier quoted context omitted.

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.

> I constantly see Kotlin advocates claiming better Java interop but I don't see how I think generally when people say this they mean things like: 1. You can freely mix and match Java and Kotlin files in the same package 2. Being a more lightweight layer on top of Java makes interop with all Java environments (specifically Android) more practical

Actually Scala 2.12 will have more Java 8 Interop than Kotlin. Scala will hit soon while I don't see Kotlin Java7/Java8 soon not even a Milestone release yet.

Re: Kotlin Post-1.0 Roadmap

#32

Post by lmm » Thu, Apr 14, 2016, 8:31 PM UTC

mike_hearn wrote: post #27

lmm wrote: post #23

Earlier quoted context omitted.

Scala Some is a box (i.e. it takes up 8 bytes on top of whatever's in it). It would be nice to represent Some(x) as just the value x (at the Java bytecode level) and None as null. The problem with that is that if you have an Option[Option[A]] you can't tell the difference between None and Some(None) (which might be semantically important), and whatever you do to solve this your Option is no longer generic and behaves…

Unfortunately boxes are not so efficient :( A box takes at least: • 4 bytes to point to it, unless you need a big heap and OOP compression isn't usable, in which case it's 8 just on the pointer. • Either 4 or 8 bytes of mark word, depending again on 32 vs 64 bit mode. • Either 4 or 8 bytes of class pointer, ditto. • Then another 4 or 8 bytes for the pointer inside the box. • GC algorithms impose some additional overh…

I very rarely want to explicitly use an Optional>. But every day I write code that works with a generic Option[A] and I want to not have to worry about what happens if someone calls it with A=Option[B]. I also frequently use Option as a parameter to some other datastructure like Kleisli or WriterT, which only works because it's an ordinary datatype that behaves like any other.

You say "you can just use the Optional class from the Java 8 standard library", but as far as I can see porting code that was written to use nullables would be a pretty big refactor, and there's no way at all to write generic code that works with both, so you'd end up having to maintain two parallel copies of your common functions.

Efforts to improve the performance of Option are of course to be applauded, but for a lot of use cases we're talking about the difference between (say) 50x faster than Ruby and 40x faster than Ruby. Scala is more than fast enough for a huge range of use cases; I don't think I've ever seen someone port code off Scala because the runtime performance wasn't good enough.

Re: Kotlin Post-1.0 Roadmap

#33

Post by acjohnson55 » Thu, Apr 14, 2016, 8:54 PM UTC

byefruit wrote: post #4

acjohnson55 wrote: post #3

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…

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.

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

Re: Kotlin Post-1.0 Roadmap

#34

Post by acjohnson55 » Thu, Apr 14, 2016, 8:57 PM UTC

mike_hearn wrote: post #26

lmm wrote: post #8

Earlier quoted context omitted.

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.

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.

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.

Re: Kotlin Post-1.0 Roadmap

#35

Post by lmm » Thu, Apr 14, 2016, 8:58 PM UTC

mike_hearn wrote: post #26

lmm wrote: post #8

Earlier quoted context omitted.

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.

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.

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

Re: Kotlin Post-1.0 Roadmap

#36

Post by acjohnson55 » Thu, Apr 14, 2016, 9:05 PM UTC

mike_hearn wrote: post #6

acjohnson55 wrote: post #3

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…

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…

You're basically talking about using an untagged union as an optional type instead of a tagged union. Last I checked, Dotty will have union types [1], so we may well see that become a more common way to express optionality. Or not. Either way, that's a pretty small distinction.

I haven't programmed Kotlin before, so I'm not sure what their answer to implicits is. For ad hoc polymorphism, none of the alternatives is particularly pretty. Perhaps the current answer is to resort to adapter classes, which would be the way to do it in Java.

[1] https://d-d.me/talks/scalaworld2015/#/6

Re: Kotlin Post-1.0 Roadmap

#37

Post by dastbe » Thu, Apr 14, 2016, 10:05 PM UTC

merb wrote: post #31

ta_donk_gt wrote: post #30

Earlier quoted context omitted.

> I constantly see Kotlin advocates claiming better Java interop but I don't see how I think generally when people say this they mean things like: 1. You can freely mix and match Java and Kotlin files in the same package 2. Being a more lightweight layer on top of Java makes interop with all Java environments (specifically Android) more practical

Actually Scala 2.12 will have more Java 8 Interop than Kotlin. Scala will hit soon while I don't see Kotlin Java7/Java8 soon not even a Milestone release yet.

This is true, but I think it's worth looking at how far behind Scala 2.12 is from its initial release date

The original roadmap: http://www.scala-lang.org/news/2.12-roadmap/ The current roadmap: http://www.scala-lang.org/news/2016-schedule/

For reference, M4 was released 3 days ago. JDK8 was released a little over 3 years ago, and JDK9 is about a year away which will introduce some interesting challenges.

We've yet to see how fast JetBrains will iterate on Kotlin and support for JDK8, while we know exactly how fast Scala iterates.

Re: Kotlin Post-1.0 Roadmap

#38

Post by merb » Fri, Apr 15, 2016, 2:19 PM UTC

dastbe wrote: post #37

merb wrote: post #31

Earlier quoted context omitted.

Actually Scala 2.12 will have more Java 8 Interop than Kotlin. Scala will hit soon while I don't see Kotlin Java7/Java8 soon not even a Milestone release yet.

This is true, but I think it's worth looking at how far behind Scala 2.12 is from its initial release date The original roadmap: http://www.scala-lang.org/news/2.12-roadmap/ The current roadmap: http://www.scala-lang.org/news/2016-schedule/ For reference, M4 was released 3 days ago. JDK8 was released a little over 3 years ago, and JDK9 is about a year away which will introduce some interesting challenges. We've yet t…

Yeah the schedule change was sad. And Scala 2.12 takes really long, but a Scala 2.11 is really solid, it just hasn't the same interop than it should have in a Java 8 world.

Re: Kotlin Post-1.0 Roadmap

#39

Post by airless_bar » Fri, Apr 15, 2016, 9:20 PM UTC

merb wrote: post #31

ta_donk_gt wrote: post #30

Earlier quoted context omitted.

> I constantly see Kotlin advocates claiming better Java interop but I don't see how I think generally when people say this they mean things like: 1. You can freely mix and match Java and Kotlin files in the same package 2. Being a more lightweight layer on top of Java makes interop with all Java environments (specifically Android) more practical

Actually Scala 2.12 will have more Java 8 Interop than Kotlin. Scala will hit soon while I don't see Kotlin Java7/Java8 soon not even a Milestone release yet.

Even Scala 2.11 has better Java 8 interop. The main change in 2.12 is that Scala itself uses Java 8 features like default methods and invokydynamic.

Using Java 8 has worked with 2.11 for quite some time already.

Re: Kotlin Post-1.0 Roadmap

#40

Post by airless_bar » Fri, Apr 15, 2016, 9:27 PM UTC

mike_hearn wrote: post #26

lmm wrote: post #8

Earlier quoted context omitted.

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.

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.

  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.

Years ago Scala tried the same thing Kotlin currently tries to sell as the hot new stuff. That approach was abandoned altogether, because. it. just. doesn't. work.

It's a death by thousand cuts. You can keep sprinkling compiler magic on top of it, but it will be an ongoing game of whack-a-mole. See all the typesystem unsoundness and how they had to abandon (non-)null annotations for existing code because it just didn't scale/work.

The whole concept of having mutable and immutable collections within the same API hierarchy that Kotlin tries to sell is also considered to be one of the remaining design issues of Scala collections.

Those were terrible times. So happy that Scala doesn't do that anymore!