6 ms·

Yeah (agree) that's not correct. Kotlin has to compile to Java bytecode, true, but it does not overlay Java like e.g. Groovy does. Kotlin and Java very much exi

by dcow 9y ago

Yeah (agree) that's not correct. Kotlin has to compile to Java bytecode, true, but it does not overlay Java like e.g. Groovy does. Kotlin and Java very much exist side-by-side in exactly the same way Swift and objective-c do: they (can) target the same machine but have different language scemantics.

pvg 9y ago
The Chris Lattner quote at the end explains the fundamental difference. Kotlin is an interloper in a Java world - that includes the JVM, a VM designed to run Java. Swift integrates and interoperates with but is not based on the Objective C runtime. Apple also controls all the relevant bits and pieces and they can bridge, compile-to, shim, wrap, etc however they want. They can can pick the design approach and fiddle with all the parts to make them fit. This isn't a luxury Kotlin has.
- peterashford 9y ago
  That would have been true to say if this was a decade ago. After the advent of .NET and CLI's ability to support multiple languages, Sun started moving the JVM away from being Java specific and including features to support other languages. Your criticism hasn't been correct for years.
  - extempore 9y ago
    It is not a criticism as much as it is a fact, no less true than ever. The JVM is designed to run Java. Other languages also compile to Java bytecode, and Sun and Oracle have made some helpful changes. But the VM is OVERWHELMINGLY designed around the requirements of Java and to be performant for Java. Try compiling a non-OO language to fast bytecode without spending a lot of time considering what the analogous Java code would compile to. Java bytecode is so close to Java, you can decompile it almost directly to readable Java source. Try that with JRuby or Clojure or Scala and see how close you land.
    - cel1ne 9y ago
      Kotlin can compile to Javascript too. Just saying.
  - pvg 9y ago
    I'm not sure I understand this, it seems you're responding to some perceived 'criticism' rather than things Lattner mentions. Yes, a few things have been tweaked in the JVM to make life easier for non-Java languages. Fundamentally, its semantics are closely tied to Java's (or vice versa or both or something!). You aren't going to write a (sanely performing) JVM language that has a different memory management model or value types or TCO - not until the JVM supports those things and even then, hopefully in a way that matches what you have in mind for your language. This isn't so much a criticism as a non-controversial fact.
    - peoplewindow 9y ago
      Up until recently it would have been non controversial. With Graal/Truffle it's possible to run many languages on the JVM whilst bypassing bytecode entirely. Those language implementations usually run as fast or much faster than other runtimes. It includes LLVM bitcode that does manual memory management, which can run at least some benchmarks about as fast as gcc would.
      - pvg 9y ago
        First you said 'not correct for years', now you're talking about stuff that's still in development and is not really the JVM anyone actually uses. I don't think you're making a good faith argument (or simply didn't click through Lattner's bit the first time around) - you just don't want to be wrong on the internet. That's fine but it's not an interesting conversation.
        peoplewindow 9y ago
        I am not peterashford, so no, I didn't say that.
        pvg 9y ago
        D'oh! My bad, apologies. But it's the dual of that argument and similarly orthogonal. Future-JVM becomes some other, more general JVM but that doesn't change the design constraints of Kotlin, its relationship to Java and how that relationship is fundamentally different than Swift's relationship to Objective C. Kotlin wasn't designed to run on Truffle or with Truffle in mind.
vorg 9y ago
> [Kotlin] does not overlay Java like e.g. Groovy does Apache Groovy 1.x was dynamically typed only, and focused on scripting and glue code for the JVM and syntactic compat with java, so could be said to "overlay Java". Since Groovy 2.0 however, it changed tack with static typing targeted for Android development, not keeping up with syntax changes in Java such as lambdas from Java 8, and tried to compete with Java instead of complementing it. It no longer "overlays Java", and in fact lost out to Kotlin and Scala in its effort to compete with Java. Groovy should have stuck to its knitting instead of changing direction every few years.

by dcow 9y ago

pvg 9y ago

The Chris Lattner quote at the end explains the fundamental difference. Kotlin is an interloper in a Java world - that includes the JVM, a VM designed to run Java. Swift integrates and interoperates with but is not based on the Objective C runtime. Apple also controls all the relevant bits and pieces and they can bridge, compile-to, shim, wrap, etc however they want. They can can pick the design approach and fiddle with all the parts to make them fit. This isn't a luxury Kotlin has.

peterashford 9y ago
That would have been true to say if this was a decade ago. After the advent of .NET and CLI's ability to support multiple languages, Sun started moving the JVM away from being Java specific and including features to support other languages. Your criticism hasn't been correct for years.
- extempore 9y ago
  It is not a criticism as much as it is a fact, no less true than ever. The JVM is designed to run Java. Other languages also compile to Java bytecode, and Sun and Oracle have made some helpful changes. But the VM is OVERWHELMINGLY designed around the requirements of Java and to be performant for Java. Try compiling a non-OO language to fast bytecode without spending a lot of time considering what the analogous Java code would compile to. Java bytecode is so close to Java, you can decompile it almost directly to readable Java source. Try that with JRuby or Clojure or Scala and see how close you land.
  - cel1ne 9y ago
    Kotlin can compile to Javascript too. Just saying.
- pvg 9y ago
  I'm not sure I understand this, it seems you're responding to some perceived 'criticism' rather than things Lattner mentions. Yes, a few things have been tweaked in the JVM to make life easier for non-Java languages. Fundamentally, its semantics are closely tied to Java's (or vice versa or both or something!). You aren't going to write a (sanely performing) JVM language that has a different memory management model or value types or TCO - not until the JVM supports those things and even then, hopefully in a way that matches what you have in mind for your language. This isn't so much a criticism as a non-controversial fact.
  - peoplewindow 9y ago
    Up until recently it would have been non controversial. With Graal/Truffle it's possible to run many languages on the JVM whilst bypassing bytecode entirely. Those language implementations usually run as fast or much faster than other runtimes. It includes LLVM bitcode that does manual memory management, which can run at least some benchmarks about as fast as gcc would.
    - pvg 9y ago
      First you said 'not correct for years', now you're talking about stuff that's still in development and is not really the JVM anyone actually uses. I don't think you're making a good faith argument (or simply didn't click through Lattner's bit the first time around) - you just don't want to be wrong on the internet. That's fine but it's not an interesting conversation.
      - peoplewindow 9y ago
        I am not peterashford, so no, I didn't say that.
        pvg 9y ago
        D'oh! My bad, apologies. But it's the dual of that argument and similarly orthogonal. Future-JVM becomes some other, more general JVM but that doesn't change the design constraints of Kotlin, its relationship to Java and how that relationship is fundamentally different than Swift's relationship to Objective C. Kotlin wasn't designed to run on Truffle or with Truffle in mind.

vorg 9y ago

> [Kotlin] does not overlay Java like e.g. Groovy does Apache Groovy 1.x was dynamically typed only, and focused on scripting and glue code for the JVM and syntactic compat with java, so could be said to "overlay Java". Since Groovy 2.0 however, it changed tack with static typing targeted for Android development, not keeping up with syntax changes in Java such as lambdas from Java 8, and tried to compete with Java instead of complementing it. It no longer "overlays Java", and in fact lost out to Kotlin and Scala in its effort to compete with Java. Groovy should have stuck to its knitting instead of changing direction every few years.