5 ms·

Between Kotlin, Ceylon [1] and Xtend [2], all recent JVM languages that aspire to be an improved Java, which one would you bet to come out on top in the long ru

Between Kotlin, Ceylon [1] and Xtend [2], all recent JVM languages that aspire to be an improved Java, which one would you bet to come out on top in the long run? [1] http://ceylon-lang.org http://ceylon-lang.org [2] http://www.eclipse.org/xtend/ http://www.eclipse.org/xtend/

harryh 11y ago
My answer to this question used to be Scala. It has orders of magnitude more traction (and is a much better language) than any of the options you mention. The fact that it hasn't "happened yet" is a bit worrisome though. To the point that I honestly think the answer at this point is Java. It will never be awesome but it will get a bit better every year.
- cdbattags 11y ago
  I believe a lot of the lack of adoption has to do with how hard it tends to be setting up the environment for Scala dev on Android. Whereas, Kotlin aims to make it as easy as possible by working hand in hand with Android Studio/IntelliJ.
  - harryh 11y ago
    I certainly agree that Typesafe (the company behind Scala) has hugely underinvested in tooling. The fact that they still (afaik) recommend sbt as a build tool is telling.
    - andreaferretti 11y ago
      I happen to find sbt one of the few build tools (together with lein) that are decent enough. Do you have any particular reason for your dislike?
      - harryh 11y ago
        It doesn't work with large codebases. Or even very well with medium sized ones.
        dragonwriter 11y ago
        > It doesn't work with large codebases. This type of general conclusion isn't, by itself, particularly useful in discussion; a lot more useful would be presenting a summary of the specific facts and experiences that lead you to this conclusion.
        saryant 11y ago
        What size are we talking? I've had no issues with SBT on a 20k line codebase.
        eeperson 11y ago
        I'm using it on a 100k line codebase without issue. What problems are you having?
        merb 11y ago
        i'm loving sbt, but still on projects above > 100 dependencies it gets really really slow to download it, while with gradle (even i dislike it) it is way way faster.
        eeperson 11y ago
        This is probably SBT's greatest weakness and Gradle's biggest strength, relatively. I've never run in to this personally, probably because I'm use Nexus[1] as a repository cache. My understanding is that the underlying problem is a limitation of the dependency resolution library they use, Ivy[2]. Gradle used to use this but at some point wrote their own dependency resolution library. There are some improvements in recent versions of SBT but you have do a little configuration. See here[3] for more details. [1] http://www.sonatype.com/nexus/product-overview http://www.sonatype.com/nexus/product-overview [2] http://ant.apache.org/ivy/ http://ant.apache.org/ivy/ [3] https://www.typesafe.com/blog/improved-dependency-management-with-sbt-0137 https://www.typesafe.com/blog/improved-dependency-management...
    - caoilte 11y ago
      sbt isn't very good for copy&paste build masters, which was pretty much all of us who had to setup Ant and Maven projects. It demands a certain amount of investment in learning its core concepts, but OMIGOD it's sooooo good once you know what you're doing. I've extracted so much common setup to hierarchies of plugins that I can setup our company's most common usecases for new projects in 3 or so lines of code.
      - kasey_junk 11y ago
        One of the big problems I had with it (stopped using it about a year ago) was that they changed those core concepts so frequently. I had code routinely stop working during point releases. I couldn't justify spending that much time on my build code.
  - incepted 11y ago
    Scala's runtime also disqualifies it from anything but toy projects on Android (something like 50k methods). This document goes in greater details: https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit?hl=en&forcehl=1 https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC...
    - harryh 11y ago
      Isn't it fairly easy to slim down the runtime at build time to only the methods you're using? I was under the impression that this was possible, though I've never actually done it so what do I know....
      - eeperson 11y ago
        Yes, it is. This is commonly accomplished with a tool called ProGuard. Doing this comes with some other trade offs but it is easy to do.
    - justthistime_ 11y ago
      Just because they didn't do their research doesn't mean it's not a no-brainer. > it requires build complexity All languages benefit from not having to deploy their standard library on every iteration, not only Scala.
cdbattags 11y ago
IMO, as with every "who will win out" scenario, it usually depends on how well word gets out, who's backing and just basic "do I like this". That being said, I really like Kotlin and the fact that it can be used easily with Android Studio and IntelliJ means I'll be watching it closely (more closely than all the rest).
txrit 11y ago
Probably Scala (although I hope Kotlin makes some inroads too), but I don't think it will ever displace Java in a significant way. Scala, outliers aside, is well loved by it's users [1], but not everyone wants to spend the time to learn it. Java remains popular because it's the nobody got fired for picking it default, not because it's technically superior to Kotlin, Celon etc. The Java language has become one of the poorest choices on the JVM and is showing its age when compared to the alternatives. We ditched Java for Scala for most work. It's fantastic to work with once you've learned it, but it's not a path for everyone who doesn't have the inclination to spend the time learning. [1] http://stackoverflow.com/research/developer-survey-2015#tech-super http://stackoverflow.com/research/developer-survey-2015#tech...
incepted 11y ago
Last I checked, Xtend generates Java, so it's kind of a non starter. A year ago, I would have put Kotlin and Ceylon on the same level in potential but Kotlin seems to have gained some momentum this past year. On the other hand, I barely hear about Ceylon, even though it's now approaching 1.1.
ExpiredLink 11y ago
Java 8
- Randgalt 11y ago
  ^^^ Winner. The reports of Java's death have been greatly exaggerated
- Babylonian 11y ago
  By default, it's the weakest of the bunch but everyone uses it because everyone else is using it.
mindcrime 11y ago
Groovy.
thefirstzealot 11y ago
Personally, even though I like all 3 languages (ceylon, kotlin and scala - no experience with xtend) I came to appreciate the vision behind ceylon lately: the language is really well designed, with very few compromises. A lot of people overlook ceylon because the language is just not promoted too well currently: even though the documentation is comprehensive, it's not focused on the features the programmers are interested about. And they need more target platforms, but they are already working on that.
- zem 11y ago
  if ceylon had better android support (codegen and tooling) i would start learning it immediately. kotlin seems like it's gotten that right; if it builds up enough momentum that there's a good third party ecosystem of android libraries i can see it doing very well in the future. it's design is not quite as nice as ceylon's, and it doesn't do as much as scala, but it's a very pleasant language to use and jetbrains has some really good tooling for it.
  - thefirstzealot 11y ago
    True, kotlin has the huge advantage that google switched to Intellij, and the team knew how to take advantage of this opportunity really well. It also helps that JetBrains is a much smaller company and with that, more focused on their core products. As opposed to that, I assume it is much harder for the ceylon team to get the entire company to support them. For example, even though vert.x 2.0 had support for ceylon, it's not clear for me if that is also the case for vert.x 3.0, and even if it is, ceylon still isn't featured as a main language on their landing page. But they are working on an Intellij plugin, which I think will be available in ceylon 1.2. And that is the first step towards Android support. Anyway, I hope both languages do well.

harryh 11y ago

My answer to this question used to be Scala. It has orders of magnitude more traction (and is a much better language) than any of the options you mention. The fact that it hasn't "happened yet" is a bit worrisome though. To the point that I honestly think the answer at this point is Java. It will never be awesome but it will get a bit better every year.

cdbattags 11y ago
I believe a lot of the lack of adoption has to do with how hard it tends to be setting up the environment for Scala dev on Android. Whereas, Kotlin aims to make it as easy as possible by working hand in hand with Android Studio/IntelliJ.
- harryh 11y ago
  I certainly agree that Typesafe (the company behind Scala) has hugely underinvested in tooling. The fact that they still (afaik) recommend sbt as a build tool is telling.
  - andreaferretti 11y ago
    I happen to find sbt one of the few build tools (together with lein) that are decent enough. Do you have any particular reason for your dislike?
    - harryh 11y ago
      It doesn't work with large codebases. Or even very well with medium sized ones.
      - dragonwriter 11y ago
        > It doesn't work with large codebases. This type of general conclusion isn't, by itself, particularly useful in discussion; a lot more useful would be presenting a summary of the specific facts and experiences that lead you to this conclusion.
      - saryant 11y ago
        What size are we talking? I've had no issues with SBT on a 20k line codebase.
      - eeperson 11y ago
        I'm using it on a 100k line codebase without issue. What problems are you having?
        merb 11y ago
        i'm loving sbt, but still on projects above > 100 dependencies it gets really really slow to download it, while with gradle (even i dislike it) it is way way faster.
        eeperson 11y ago
        This is probably SBT's greatest weakness and Gradle's biggest strength, relatively. I've never run in to this personally, probably because I'm use Nexus[1] as a repository cache. My understanding is that the underlying problem is a limitation of the dependency resolution library they use, Ivy[2]. Gradle used to use this but at some point wrote their own dependency resolution library. There are some improvements in recent versions of SBT but you have do a little configuration. See here[3] for more details. [1] http://www.sonatype.com/nexus/product-overview http://www.sonatype.com/nexus/product-overview [2] http://ant.apache.org/ivy/ http://ant.apache.org/ivy/ [3] https://www.typesafe.com/blog/improved-dependency-management-with-sbt-0137 https://www.typesafe.com/blog/improved-dependency-management...
  - caoilte 11y ago
    sbt isn't very good for copy&paste build masters, which was pretty much all of us who had to setup Ant and Maven projects. It demands a certain amount of investment in learning its core concepts, but OMIGOD it's sooooo good once you know what you're doing. I've extracted so much common setup to hierarchies of plugins that I can setup our company's most common usecases for new projects in 3 or so lines of code.
    - kasey_junk 11y ago
      One of the big problems I had with it (stopped using it about a year ago) was that they changed those core concepts so frequently. I had code routinely stop working during point releases. I couldn't justify spending that much time on my build code.
- incepted 11y ago
  Scala's runtime also disqualifies it from anything but toy projects on Android (something like 50k methods). This document goes in greater details: https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit?hl=en&forcehl=1 https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhC...
  - harryh 11y ago
    Isn't it fairly easy to slim down the runtime at build time to only the methods you're using? I was under the impression that this was possible, though I've never actually done it so what do I know....
    - eeperson 11y ago
      Yes, it is. This is commonly accomplished with a tool called ProGuard. Doing this comes with some other trade offs but it is easy to do.
  - justthistime_ 11y ago
    Just because they didn't do their research doesn't mean it's not a no-brainer. > it requires build complexity All languages benefit from not having to deploy their standard library on every iteration, not only Scala.

cdbattags 11y ago

IMO, as with every "who will win out" scenario, it usually depends on how well word gets out, who's backing and just basic "do I like this". That being said, I really like Kotlin and the fact that it can be used easily with Android Studio and IntelliJ means I'll be watching it closely (more closely than all the rest).

txrit 11y ago

Probably Scala (although I hope Kotlin makes some inroads too), but I don't think it will ever displace Java in a significant way. Scala, outliers aside, is well loved by it's users [1], but not everyone wants to spend the time to learn it. Java remains popular because it's the nobody got fired for picking it default, not because it's technically superior to Kotlin, Celon etc. The Java language has become one of the poorest choices on the JVM and is showing its age when compared to the alternatives. We ditched Java for Scala for most work. It's fantastic to work with once you've learned it, but it's not a path for everyone who doesn't have the inclination to spend the time learning. [1] http://stackoverflow.com/research/developer-survey-2015#tech-super http://stackoverflow.com/research/developer-survey-2015#tech...

incepted 11y ago

Last I checked, Xtend generates Java, so it's kind of a non starter. A year ago, I would have put Kotlin and Ceylon on the same level in potential but Kotlin seems to have gained some momentum this past year. On the other hand, I barely hear about Ceylon, even though it's now approaching 1.1.

ExpiredLink 11y ago

Java 8

Randgalt 11y ago
^^^ Winner. The reports of Java's death have been greatly exaggerated
Babylonian 11y ago
By default, it's the weakest of the bunch but everyone uses it because everyone else is using it.

mindcrime 11y ago

Groovy.

thefirstzealot 11y ago

Personally, even though I like all 3 languages (ceylon, kotlin and scala - no experience with xtend) I came to appreciate the vision behind ceylon lately: the language is really well designed, with very few compromises. A lot of people overlook ceylon because the language is just not promoted too well currently: even though the documentation is comprehensive, it's not focused on the features the programmers are interested about. And they need more target platforms, but they are already working on that.

zem 11y ago
if ceylon had better android support (codegen and tooling) i would start learning it immediately. kotlin seems like it's gotten that right; if it builds up enough momentum that there's a good third party ecosystem of android libraries i can see it doing very well in the future. it's design is not quite as nice as ceylon's, and it doesn't do as much as scala, but it's a very pleasant language to use and jetbrains has some really good tooling for it.
- thefirstzealot 11y ago
  True, kotlin has the huge advantage that google switched to Intellij, and the team knew how to take advantage of this opportunity really well. It also helps that JetBrains is a much smaller company and with that, more focused on their core products. As opposed to that, I assume it is much harder for the ceylon team to get the entire company to support them. For example, even though vert.x 2.0 had support for ceylon, it's not clear for me if that is also the case for vert.x 3.0, and even if it is, ceylon still isn't featured as a main language on their landing page. But they are working on an Intellij plugin, which I think will be available in ceylon 1.2. And that is the first step towards Android support. Anyway, I hope both languages do well.