4 ms·

Kotlin is one fine piece of engineering. It's only too unfortunate that the same Achilles' heel is holding it back as Scala: there is only so much you can do wh

Kotlin is one fine piece of engineering. It's only too unfortunate that the same Achilles' heel is holding it back as Scala: there is only so much you can do while remaining compatible with JVM and the Java standard library. Actually, it's even worse: Kotlin swore a seamless compatibility with Java. Maintaining compatibility against a moving target has the potential to make things quite messy. An early example of that presented itself just after Kotlin 1.0 release, when Java 8 came out with with new and shiny functional Collections API - incompatible to Kotlin's.

jorgemf 10y ago
The new Collections API wasn't incompatible with kotlin, it is just you can use the new API if you target Java 6 (which makes sense). But you can use the new API if you target Java 8. So I don't see a big deal here. The problem is not the compatibility with the new Java API, but with the new bytecode definition. But it is going to have the same problems Java have. The big difference with Java here is that you can adopt new bytecode specifications without using the new Java APIs, or doing some modification in the bytecode generation to "simulate" those new features. And this is the key why it is taking over Android community. You can support legacy bytecode with new features. Which you cannot do with Java. A problem for kotlin (and java) is the new packaging system. But kotlin is already working on it changing how they package their standard library. So it is even less problem than java.
- kirillkh 10y ago
  > The new Collections API wasn't incompatible with kotlin There definitely is a problem, as can be seen e.g. here: https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotlin/73/6 https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotl... Quoting: "Sometime ago we introduced kotlin.Stream<T> type, with the simples possible interface – iterator() function – with the idea that we can make it compatible with Java8 Stream<T> type. Currently we seem to come to a conclusion it was a mistake as we cannot fine a way to represent Stream<T> as kotlin type in Java 6 & 7, and then use to Java8's Stream<T> when targeting JDK8. If you have any idea about how to make it work – please share!" Basically, while Kotlin is more or less a straightforward extension of the Java 6'th Collections APIs, by Java 8's release the two have diverged. When programming in Kotlin, you would normally use its own functional APIs, not Java Streams API. While technically nothing prevents you from using Streams, they don't fully integrate with Kotlin's native Collections, so you're forced to choose one or another.
  - jorgemf 10y ago
    That more or less what I said, it is not incompatible as you can use the Java stream API if you target Java 8. But yes, it is a pain when you see you have to use the Java Stream API instead of the kotlin Stream API. Not incompatible but an issue. And they seem to have resolved it. Look at last comment. What you are quoting is from December 14th, before even the initial 1.0 release of kotlin.
    - kirillkh 10y ago
      Like I said, Kotlin is chasing after a moving target. The issues might be kinda-solvable (even if it requires significantly diverging from Java's APIs), but things inevitably get messier both for the language internals and for users.
pron 10y ago
> It's only too unfortunate that the same Achilles' heel is holding it back as Scala: there is only so much you can do while remaining compatible with JVM and the Java standard library. Being part of the largest, most successful, best tooled ecosystem in software is an Achilles' heel? Most people would (and should) gladly take that over any particular language feature.
- bsaul 10y ago
  I'm really not proficient with the jvm ( my only experience with it has been slow start time and huge memory consumption). Could you give some example oF unique features of the toolsuite around the jvm ?
  - mike_hearn 10y ago
    JVM can run "Hello World" in about 50msec these days. The java guys do care about startup time, you can see if you read their mailing lists that they are constantly trying to defend their startup time as new features come in that add initialisation work. It's a priority. Still, the reason many Java apps may feel like they start slowly is that they tend to do a lot. The app I'm currently working on starts in about 5 seconds, which isn't terrible by the standards of the space but isn't great either. But the reason is that that 5 seconds involves initialising an entire message queue broker, an entire relational database and an entire web server. These aren't tiny 'embedded' versions either: they're Artemis, H2 and Jetty, which are both also used standalone and have cutting edge featuresets. If we weren't using the JVM then we'd presumably be using some container based solution and starting postgres, some other MQ broker and apache or something. Bringing up such a container from scratch could easily take 5 seconds or more I think. The JVM will by default use all the memory on your machine. This is an unintuitive default, to put it mildly. The reason is that the JVM can make your software run faster by using more memory. Doubling RAM is easy. Doubling your CPU cores whilst keeping them actually used is hard, doubling the speed of an individual CPU core at this point appears to be nearly impossible. So it makes sense in a technical way. But it does make it hard to judge memory bloat. Again, speaking about the app I currently work on, I got a support request the other week from someone who wanted to run the app on a Raspberry Pi and was complaining it took much memory. Quick testing showed we actually only needed about 50-75mb of heap and simply telling the JVM to limit the Java heap to that size slaughtered memory usage and resolved the problem. Not hard to check that and configure things for small devices, but it's a knob you can't/don't need to twist when using manual memory management, or GCs designed for mobile/laptop devices where minimising memory usage took priority over raw runtime performance.
hota_mazi 10y ago
> when Java 8 came out with with new and shiny functional Collections API - incompatible to Kotlin's. This makes no sense. Kotlin has no collections, it just uses Java's.
- pjmlp 10y ago
  He/she means the changes related to streams, I would say.
- kirillkh 10y ago
  Kotlin has an extensive Collections library, which started largely as an extension of Java's, but now it offers much more. In any case, I was referering to Kotlin's APIs, not Collections per se, and it certainly has its own APIs.

jorgemf 10y ago

The new Collections API wasn't incompatible with kotlin, it is just you can use the new API if you target Java 6 (which makes sense). But you can use the new API if you target Java 8. So I don't see a big deal here. The problem is not the compatibility with the new Java API, but with the new bytecode definition. But it is going to have the same problems Java have. The big difference with Java here is that you can adopt new bytecode specifications without using the new Java APIs, or doing some modification in the bytecode generation to "simulate" those new features. And this is the key why it is taking over Android community. You can support legacy bytecode with new features. Which you cannot do with Java. A problem for kotlin (and java) is the new packaging system. But kotlin is already working on it changing how they package their standard library. So it is even less problem than java.

kirillkh 10y ago
> The new Collections API wasn't incompatible with kotlin There definitely is a problem, as can be seen e.g. here: https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotlin/73/6 https://discuss.kotlinlang.org/t/jdk-8-compatibility-of-kotl... Quoting: "Sometime ago we introduced kotlin.Stream<T> type, with the simples possible interface – iterator() function – with the idea that we can make it compatible with Java8 Stream<T> type. Currently we seem to come to a conclusion it was a mistake as we cannot fine a way to represent Stream<T> as kotlin type in Java 6 & 7, and then use to Java8's Stream<T> when targeting JDK8. If you have any idea about how to make it work – please share!" Basically, while Kotlin is more or less a straightforward extension of the Java 6'th Collections APIs, by Java 8's release the two have diverged. When programming in Kotlin, you would normally use its own functional APIs, not Java Streams API. While technically nothing prevents you from using Streams, they don't fully integrate with Kotlin's native Collections, so you're forced to choose one or another.
- jorgemf 10y ago
  That more or less what I said, it is not incompatible as you can use the Java stream API if you target Java 8. But yes, it is a pain when you see you have to use the Java Stream API instead of the kotlin Stream API. Not incompatible but an issue. And they seem to have resolved it. Look at last comment. What you are quoting is from December 14th, before even the initial 1.0 release of kotlin.
  - kirillkh 10y ago
    Like I said, Kotlin is chasing after a moving target. The issues might be kinda-solvable (even if it requires significantly diverging from Java's APIs), but things inevitably get messier both for the language internals and for users.

pron 10y ago

> It's only too unfortunate that the same Achilles' heel is holding it back as Scala: there is only so much you can do while remaining compatible with JVM and the Java standard library. Being part of the largest, most successful, best tooled ecosystem in software is an Achilles' heel? Most people would (and should) gladly take that over any particular language feature.

bsaul 10y ago
I'm really not proficient with the jvm ( my only experience with it has been slow start time and huge memory consumption). Could you give some example oF unique features of the toolsuite around the jvm ?
- mike_hearn 10y ago
  JVM can run "Hello World" in about 50msec these days. The java guys do care about startup time, you can see if you read their mailing lists that they are constantly trying to defend their startup time as new features come in that add initialisation work. It's a priority. Still, the reason many Java apps may feel like they start slowly is that they tend to do a lot. The app I'm currently working on starts in about 5 seconds, which isn't terrible by the standards of the space but isn't great either. But the reason is that that 5 seconds involves initialising an entire message queue broker, an entire relational database and an entire web server. These aren't tiny 'embedded' versions either: they're Artemis, H2 and Jetty, which are both also used standalone and have cutting edge featuresets. If we weren't using the JVM then we'd presumably be using some container based solution and starting postgres, some other MQ broker and apache or something. Bringing up such a container from scratch could easily take 5 seconds or more I think. The JVM will by default use all the memory on your machine. This is an unintuitive default, to put it mildly. The reason is that the JVM can make your software run faster by using more memory. Doubling RAM is easy. Doubling your CPU cores whilst keeping them actually used is hard, doubling the speed of an individual CPU core at this point appears to be nearly impossible. So it makes sense in a technical way. But it does make it hard to judge memory bloat. Again, speaking about the app I currently work on, I got a support request the other week from someone who wanted to run the app on a Raspberry Pi and was complaining it took much memory. Quick testing showed we actually only needed about 50-75mb of heap and simply telling the JVM to limit the Java heap to that size slaughtered memory usage and resolved the problem. Not hard to check that and configure things for small devices, but it's a knob you can't/don't need to twist when using manual memory management, or GCs designed for mobile/laptop devices where minimising memory usage took priority over raw runtime performance.

hota_mazi 10y ago

> when Java 8 came out with with new and shiny functional Collections API - incompatible to Kotlin's. This makes no sense. Kotlin has no collections, it just uses Java's.

pjmlp 10y ago
He/she means the changes related to streams, I would say.
kirillkh 10y ago
Kotlin has an extensive Collections library, which started largely as an extension of Java's, but now it offers much more. In any case, I was referering to Kotlin's APIs, not Collections per se, and it certainly has its own APIs.