5 ms·

I'm really rooting for kotlin - it seems like a good runner up to scala without the poor compile times. Looking forward to a 1.0 release

mercurial 13y ago
I think it's massively less ambitious, which is a good point in its favour.
- jes5199 13y ago
  It might be the least ambitious new language of the last ten years!
  - Avshalom 13y ago
    I think that trophy is won pretty handily by Go.
    - tomp 13y ago
      I wanted to say Go as well, but compared to any other possibly-mainstream languages, Go is very innovative - it has fibres/goroutines, channels, and structural typing/lack of class-based inheritance!
      - effn 13y ago
        The bar for what counts as "innovation" in mainstream languages is strikingly low.
      - thescrewdriver 13y ago
        All of which are available in other languages...
        Avshalom 13y ago
        In addition to the fact that none of it's features are particularly novel lets remember that Go's founding ambition was "compile faster than C++"
        jfb 13y ago
        And people disparage them for it, which is nuts. Google had a problem that they determined could best be solved by creating Go. So they did it, and presumably, they've solved their problem. That seems like a perfectly good use of incremental improvement. Which raises an interesting point: what to people on the outside looks like a paradoxical combination of insane hubris and deep technical conservatism is probably simply what to Google's eyes looks like steady-state, responsible technical problem-solving -- c.f., hhvm and Facebook for a similar approach.
        lanna 13y ago
        > Go's founding ambition was "compile faster than C++" And Kotlin's is "compile faster than Scala"!
    - rst 13y ago
      Actually, Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick. (Which doesn't completely excuse the "C++ tried that and it didn't work for them so WE WON'T" foot-dragging on other matters...)
      - voidlogic 13y ago
        >Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick For those that don't know this feature is called structural typing: http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system Also, OCaml uses structural typing too.
      - pjmlp 13y ago
        No it was not, there are lots of languages that offer similar capabilities. The fact that mainstream developers don't know it, does not make it something that Go designers invented.
      - eropple 13y ago
        OCaml already had structural typing. Scala does too.
    - bguthrie 13y ago
      Actually I think Hack might've just surpassed it.
  - tomp 13y ago
    You mean, except Dart.
    - frowaway001 13y ago
      Let's just agree that Google couldn't design a language even if its life depended on it.
      - bryanlarsen 13y ago
        How about "Google has a surprisingly conservative culture".
        frowaway001 13y ago
        I wouldn't call "ignoring stuff from 1970" conservative.
        thescrewdriver 13y ago
        They're using Java very widely, you don't get much more conservative than that.
gecko 13y ago
Kotlin's brilliance is how much less it's trying to do. It's truly narrowly focused on fixing what's broken in Java—not introducing an entirely new language that happens to compile to the JVM. That'll make adopting it in organizations much easier, converting code to it much easier, and so on. That said, I never figured out why Xtend (http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/) never caught on, and it delivered most of what Kotlin is now offering, but with an even more Java-like syntax right out-of-the-box. Since Kotlin and Xtend are very, very similar, I suspect that Kotlin's ability to genuinely succeed will be mostly based on JetBrains' popularity how strongly they push it.
- thescrewdriver 13y ago
  > I never figured out why Xtend (http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/) never caught on.... > ... with an even more Java-like syntax I think you have your answer right there. The other reason is that nobody likes the idea of having a language which compiles to Java source code.
  - Dewie 13y ago
    > The other reason is that nobody likes the idea of having a language which compiles to Java source code. Why not? It seems like a good thing if there is a possibility that you might have to go back to Java (if that make sense) or if some time down the road it is simpler for maintainers to go over to Java by reading the compiler output rather than dealing with xtend, if they don't know it. It could also be great if you want to quickly know what the equivalent of what you are writing in xtend is in java - just compile it. That seems more interactive than having to google or look up on StackOverflow. Of course this assumes that the compiler output is actually readable.
  - gecko 13y ago
    People have no real problem with languages that compile to C or JavaScript, so I'm not really convinced that's the problem as such. The lack of source maps/#line pragmas in Java didn't help, I'm sure, but these are solvable problems if there's interest (as demonstrated by #line and source maps).
pron 13y ago
Plus, its interoperation with Java is so seamless, that adoption is both gradual and natural.
lmm 13y ago
I'm not really seeing the case for Kotlin. If I want the most powerful language possible on the JVM, I use Scala. If I want a clean and elegant language, I use Ceylon - I don't think you can get that from a language that keeps the Java standard library. Prior to Java 8 I could maybe see the case for a language that's just Java with lambda and a few other niceties, but now that Java 8's out, if I'm going to go to the trouble of switching to a new language I want a bigger return on that cost than Kotlin offers.
- pjmlp 13y ago
  A good alternative for Java on Android given Google's fork and not so good support for Scala and Clojure on Dalvik/ART?
  - lmm 13y ago
    Oh, I just wrote my (one, rather simple) android app in Scala. Are there problems with it?
    - thescrewdriver 13y ago
      It tends to generate lots of anonymous classes, which can make your jar bigger.
    - pjmlp 13y ago
      Executables are slower and bigger than Java even with ProGuard, specially given how outdated Dalvik GC/JIT are. Maybe this will improve with ART.
      - pkuki 13y ago
        Maybe they are slower to some extend, but for most cases it won't matter too much. I wrote simple game in scala and it was easy to constantly get 55-60 fps on newer devices: https://github.com/pkukielka/stronghold-defense https://github.com/pkukielka/stronghold-defense That being said I agree that jars are bigger and scala generates much more anonymous classes. Even with ProGuard that could be a problem on Android 2.3 or older. And ProGuard is a bit slow (for my game it was taking 30+ seconds for every build). Also Typesafe doesn't have plans for making scala first class citizen of Android. So while Android development with scala is certainly possible there are few inconveniences which one should be aware of.

mercurial 13y ago

I think it's massively less ambitious, which is a good point in its favour.

jes5199 13y ago
It might be the least ambitious new language of the last ten years!
- Avshalom 13y ago
  I think that trophy is won pretty handily by Go.
  - tomp 13y ago
    I wanted to say Go as well, but compared to any other possibly-mainstream languages, Go is very innovative - it has fibres/goroutines, channels, and structural typing/lack of class-based inheritance!
    - effn 13y ago
      The bar for what counts as "innovation" in mainstream languages is strikingly low.
    - thescrewdriver 13y ago
      All of which are available in other languages...
      - Avshalom 13y ago
        In addition to the fact that none of it's features are particularly novel lets remember that Go's founding ambition was "compile faster than C++"
        jfb 13y ago
        And people disparage them for it, which is nuts. Google had a problem that they determined could best be solved by creating Go. So they did it, and presumably, they've solved their problem. That seems like a perfectly good use of incremental improvement. Which raises an interesting point: what to people on the outside looks like a paradoxical combination of insane hubris and deep technical conservatism is probably simply what to Google's eyes looks like steady-state, responsible technical problem-solving -- c.f., hhvm and Facebook for a similar approach.
        lanna 13y ago
        > Go's founding ambition was "compile faster than C++" And Kotlin's is "compile faster than Scala"!
  - rst 13y ago
    Actually, Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick. (Which doesn't completely excuse the "C++ tried that and it didn't work for them so WE WON'T" foot-dragging on other matters...)
    - voidlogic 13y ago
      >Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick For those that don't know this feature is called structural typing: http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system Also, OCaml uses structural typing too.
    - pjmlp 13y ago
      No it was not, there are lots of languages that offer similar capabilities. The fact that mainstream developers don't know it, does not make it something that Go designers invented.
    - eropple 13y ago
      OCaml already had structural typing. Scala does too.
  - bguthrie 13y ago
    Actually I think Hack might've just surpassed it.
- tomp 13y ago
  You mean, except Dart.
  - frowaway001 13y ago
    Let's just agree that Google couldn't design a language even if its life depended on it.
    - bryanlarsen 13y ago
      How about "Google has a surprisingly conservative culture".
      - frowaway001 13y ago
        I wouldn't call "ignoring stuff from 1970" conservative.
      - thescrewdriver 13y ago
        They're using Java very widely, you don't get much more conservative than that.

gecko 13y ago

Kotlin's brilliance is how much less it's trying to do. It's truly narrowly focused on fixing what's broken in Java—not introducing an entirely new language that happens to compile to the JVM. That'll make adopting it in organizations much easier, converting code to it much easier, and so on. That said, I never figured out why Xtend (http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/) never caught on, and it delivered most of what Kotlin is now offering, but with an even more Java-like syntax right out-of-the-box. Since Kotlin and Xtend are very, very similar, I suspect that Kotlin's ability to genuinely succeed will be mostly based on JetBrains' popularity how strongly they push it.

thescrewdriver 13y ago
> I never figured out why Xtend (http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/) never caught on.... > ... with an even more Java-like syntax I think you have your answer right there. The other reason is that nobody likes the idea of having a language which compiles to Java source code.
- Dewie 13y ago
  > The other reason is that nobody likes the idea of having a language which compiles to Java source code. Why not? It seems like a good thing if there is a possibility that you might have to go back to Java (if that make sense) or if some time down the road it is simpler for maintainers to go over to Java by reading the compiler output rather than dealing with xtend, if they don't know it. It could also be great if you want to quickly know what the equivalent of what you are writing in xtend is in java - just compile it. That seems more interactive than having to google or look up on StackOverflow. Of course this assumes that the compiler output is actually readable.
- gecko 13y ago
  People have no real problem with languages that compile to C or JavaScript, so I'm not really convinced that's the problem as such. The lack of source maps/#line pragmas in Java didn't help, I'm sure, but these are solvable problems if there's interest (as demonstrated by #line and source maps).

pron 13y ago

Plus, its interoperation with Java is so seamless, that adoption is both gradual and natural.

lmm 13y ago

I'm not really seeing the case for Kotlin. If I want the most powerful language possible on the JVM, I use Scala. If I want a clean and elegant language, I use Ceylon - I don't think you can get that from a language that keeps the Java standard library. Prior to Java 8 I could maybe see the case for a language that's just Java with lambda and a few other niceties, but now that Java 8's out, if I'm going to go to the trouble of switching to a new language I want a bigger return on that cost than Kotlin offers.

pjmlp 13y ago
A good alternative for Java on Android given Google's fork and not so good support for Scala and Clojure on Dalvik/ART?
- lmm 13y ago
  Oh, I just wrote my (one, rather simple) android app in Scala. Are there problems with it?
  - thescrewdriver 13y ago
    It tends to generate lots of anonymous classes, which can make your jar bigger.
  - pjmlp 13y ago
    Executables are slower and bigger than Java even with ProGuard, specially given how outdated Dalvik GC/JIT are. Maybe this will improve with ART.
    - pkuki 13y ago
      Maybe they are slower to some extend, but for most cases it won't matter too much. I wrote simple game in scala and it was easy to constantly get 55-60 fps on newer devices: https://github.com/pkukielka/stronghold-defense https://github.com/pkukielka/stronghold-defense That being said I agree that jars are bigger and scala generates much more anonymous classes. Even with ProGuard that could be a problem on Android 2.3 or older. And ProGuard is a bit slow (for my game it was taking 30+ seconds for every build). Also Typesafe doesn't have plans for making scala first class citizen of Android. So while Android development with scala is certainly possible there are few inconveniences which one should be aware of.