10 ms·

The features look very inviting. When choosing a language for a new project, I am torn between Kotlin, Scala, and now, Ceylon. Scala had its time, and I was a

by hrjet 12y ago

The features look very inviting. When choosing a language for a new project, I am torn between Kotlin, Scala, and now, Ceylon. Scala had its time, and I was a frequent user, but now I am not sure where it is going. It certainly helped bring functional programming into my vocabulary, and into a lot of other developers' too. But I get the impression that it tries to appease to many different notions, and lacks a core guiding principle. (In a more positive light: it is more democratic). Kotlin and Ceylon seem to be more streamlined, and centered on a few core principles. Ofcourse, I haven't actually coded in them, so they might be presently appearing rosier than they are. Especially after trying Xtend, I realized that there are many corner-case (but important) scenarios that burn you when you actually try a non-trivial project in these new languages. Would love to hear experiences from those who are using Kotlin, Ceylon or Xtend in production.

danieldk 12y ago
I didn't use Kotlin in production, but non-nullable types are a blessing and a curse. Non-nullable types are long-overdue. However, most Java libraries do not have non-nullable annotations. So, even if e.g. method arguments should never be null, they are presented as nullable. You can use external annotations[1], but they are a lot of work. Also, you need to ensure that anyone using your code has the same external annotations, and that they are still correct when a library is updated. There is also a tool that can automatically infer the annotations[2], but last time I tried it was definitely not perfect. Of course, it's possible to live with this, but like Scala a lot particularities of the underlying platform leak into the stronger typing and abstractions that these languages provide. [1] http://blog.jetbrains.com/kotlin/using-external-annotations/ http://blog.jetbrains.com/kotlin/using-external-annotations/ [2] http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-out/ http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-o...
- gavinking 12y ago
  Well it all depends how you handle `null` at the boundary between the two languages. In Ceylon, we let you write either: String str = javaObject.javaMethod(); or: String? str = javaObject.javaMethod(); In the first case, we insert a runtime type check that throws an `AssertionError` if `javaMethod()` returns `null`. In the second case we don't. That is to say, the Ceylon compiler recognizes that it's dealing with a Java library where information about null is simply missing from the method signature and adjusts accordingly.
  - quarterto 12y ago
    The first case would be a compile time error in Kotlin. How is a runtime AssertionError better than a runtime NullPointerException?
    - newgame 12y ago
      > The first case would be a compile time error in Kotlin FYI, Kotlin will have the same behavior as Ceylon in the future, i.e. it's going to be a runtime error in the first case: http://blog.jetbrains.com/kotlin/2014/10/making-platform-interop-even-smoother/ http://blog.jetbrains.com/kotlin/2014/10/making-platform-int...
    - gavinking 12y ago
      Well it is somewhat better because it occurs immediately when the null value passes from Java code with unsafe null into Ceylon code with safe nulls. Having the compiler produce an actual error in this case seems wrong and excessive, since the compiler does _not_ know better than you whether javaMethod() can return null. It simply doesn't have that information when calling Java code.
- mike_hearn 12y ago
  The next release of Kotlin has a change to the type system to make this a lot less painful, apparently. I'm waiting for it before proceeding with Kotlin. As to kotlin vs ceylon, no real strong preference either way, they both seem strong. I'm planning on going with Kotlin longer term because I am already an IntelliJ user and because it has a Java-to-Kotlin converter.
adriaanm 12y ago
(Scala tech lead at Typesafe here) > Scala had its time, and I was a frequent user, but now I am not sure where it is going. It certainly helped bring functional programming into my vocabulary, and into a lot of other developers' too. But I get the impression that it tries to appease to many different notions, and lacks a core guiding principle. (In a more positive light: it is more democratic). You sure piqued my interest there! Could you elaborate? Why do you say you don't know where Scala is going? Our roadmap is intended to be pretty simple: stability + full Java 8 support. Our guiding principle is to make sure your investment in your Scala codebase is safe in the long term, which entails a tricky balance between stability and getting rid of stuff that turned out not to work that well (we do this slowly, though still much faster than Java). I'm glad you feel we're more democratic. We certainly try to be transparent in what we decide to work on as a company (which implies the community is welcome to pick up our slack, and we do try to help out where we can -- see e.g., the Typelevel fork).
- hrjet 12y ago
  Thanks for your response. I appreciate all the work going into the Scala ecosystem. > Why do you say you don't know where Scala is going? Apologies for that wording. A more elaborate wording would be: I don't know where Scala as a whole (the community + language) will be heading and that is in huge part because of I not having the resources to follow the developments. I sometimes lurk in the internal discussions list and catch up with conversations, some of which tend to be controversial, but I am glad they happen in the open. (Top of mind: CPS plugin related discussions) I still use Scala whenever I can, but when it comes to performance (cpu limited), I fall back to Java. (I am aware of the compiler plugins of yore and the macros of now that help speed things, and the tree shakers, but they are third-party / require different workflows, and hence I don't feel inclined to use them for certain projects). It is mostly in this space that I am exploring alternatives. Kotlin and Ceylon seem to be more streamlined (conceptually, and hopefully at run-time), but as I haven't actually used them, I am not sure what deficiencies to expect. Edit: Removed a sidenote. Would have been a distraction.
  - adriaanm 12y ago
    Thanks for clarifying. I understand your concern. The Scala side of our commercial offering aims to alleviate those worries. Please get in touch if you'd like more details on that.
pron 12y ago
Kotlin and Ceylon are very similar feature-wise, but their ambitions and tradeoffs are completely opposite. Ceylon tries to remake and replace the JDK with new libraries (i.e. modernize everything) while Kotlin has Java interoperability as one of its top priorities, at the expense of some compromises in the language/libraries. I think that Kotlin takes the more pragmatic approach, and introduces much less risk to the project (I use Kotlin and Java classes in the same package, and it's very easy to replace one with the other). So while neither is as mature as Scala (I really don't like Scala but I won't get into that again), Kotlin is as close to risk-free as possible, while Ceylon is more ambitious. It comes down to your personal preference: are you an idealist or a pragmatist (said half jokingly)?
- gavinking 12y ago
  FTR, Ceylon's Java interop is _excellent_, especially in this latest release, and Ceylon makes it absurdly easy to use the Java SDK directly from Ceylon. Indeed, the Ceylon compiler's Java backend is actually built on Open JDK - that is, it is essentially `javac` itself that generates the bytecode - so we know that the bytecode we generate is extremely close to what Java itself would generate, including full information about generic types that the Java compiler can understand. So, sure, we have the language module, and `ceylon.collection`, `ceylon.locale`, etc, which abstract away from the JVM, but that's necessary, since Ceylon also runs on JavaScript VMs. That _doesn't_ mean you can't easily use `java.lang`, `java.util`, and the rest of the Java SDK if you need it. So it's not quite right to think that Ceylon is lacking in this area. It's actually a strong point of the language.
  - pron 12y ago
    I don't think it's lacking (only lacking wrt Kotlin), but that it isn't one of the top two concerns of the language: i.e. it's possible and maybe kind of easy, but certainly not seamless. This might be (and I don't know enough about it, so this is conjecture) one of the reasons why writing Kotlin on Android is pretty simple, while Ceylon not so much. Kotlin also compiles to JavaScript, but it's much more a "hosted" language than one that tries to abstract away the host's native APIs. You're doing great work with Ceylon, I like the type system, and I certainly wouldn't mind a "new JDK" that's as good as the current one minus all the warts that have accumulated over the years, but adopting Ceylon today, I think, is a much bigger risk than adopting Kotlin.

by hrjet 12y ago

danieldk 12y ago

I didn't use Kotlin in production, but non-nullable types are a blessing and a curse. Non-nullable types are long-overdue. However, most Java libraries do not have non-nullable annotations. So, even if e.g. method arguments should never be null, they are presented as nullable. You can use external annotations[1], but they are a lot of work. Also, you need to ensure that anyone using your code has the same external annotations, and that they are still correct when a library is updated. There is also a tool that can automatically infer the annotations[2], but last time I tried it was definitely not perfect. Of course, it's possible to live with this, but like Scala a lot particularities of the underlying platform leak into the stronger typing and abstractions that these languages provide. [1] http://blog.jetbrains.com/kotlin/using-external-annotations/ http://blog.jetbrains.com/kotlin/using-external-annotations/ [2] http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-out/ http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-o...

gavinking 12y ago
Well it all depends how you handle `null` at the boundary between the two languages. In Ceylon, we let you write either: String str = javaObject.javaMethod(); or: String? str = javaObject.javaMethod(); In the first case, we insert a runtime type check that throws an `AssertionError` if `javaMethod()` returns `null`. In the second case we don't. That is to say, the Ceylon compiler recognizes that it's dealing with a Java library where information about null is simply missing from the method signature and adjusts accordingly.
- quarterto 12y ago
  The first case would be a compile time error in Kotlin. How is a runtime AssertionError better than a runtime NullPointerException?
  - newgame 12y ago
    > The first case would be a compile time error in Kotlin FYI, Kotlin will have the same behavior as Ceylon in the future, i.e. it's going to be a runtime error in the first case: http://blog.jetbrains.com/kotlin/2014/10/making-platform-interop-even-smoother/ http://blog.jetbrains.com/kotlin/2014/10/making-platform-int...
  - gavinking 12y ago
    Well it is somewhat better because it occurs immediately when the null value passes from Java code with unsafe null into Ceylon code with safe nulls. Having the compiler produce an actual error in this case seems wrong and excessive, since the compiler does _not_ know better than you whether javaMethod() can return null. It simply doesn't have that information when calling Java code.
mike_hearn 12y ago
The next release of Kotlin has a change to the type system to make this a lot less painful, apparently. I'm waiting for it before proceeding with Kotlin. As to kotlin vs ceylon, no real strong preference either way, they both seem strong. I'm planning on going with Kotlin longer term because I am already an IntelliJ user and because it has a Java-to-Kotlin converter.

adriaanm 12y ago

(Scala tech lead at Typesafe here) > Scala had its time, and I was a frequent user, but now I am not sure where it is going. It certainly helped bring functional programming into my vocabulary, and into a lot of other developers' too. But I get the impression that it tries to appease to many different notions, and lacks a core guiding principle. (In a more positive light: it is more democratic). You sure piqued my interest there! Could you elaborate? Why do you say you don't know where Scala is going? Our roadmap is intended to be pretty simple: stability + full Java 8 support. Our guiding principle is to make sure your investment in your Scala codebase is safe in the long term, which entails a tricky balance between stability and getting rid of stuff that turned out not to work that well (we do this slowly, though still much faster than Java). I'm glad you feel we're more democratic. We certainly try to be transparent in what we decide to work on as a company (which implies the community is welcome to pick up our slack, and we do try to help out where we can -- see e.g., the Typelevel fork).

hrjet 12y ago
Thanks for your response. I appreciate all the work going into the Scala ecosystem. > Why do you say you don't know where Scala is going? Apologies for that wording. A more elaborate wording would be: I don't know where Scala as a whole (the community + language) will be heading and that is in huge part because of I not having the resources to follow the developments. I sometimes lurk in the internal discussions list and catch up with conversations, some of which tend to be controversial, but I am glad they happen in the open. (Top of mind: CPS plugin related discussions) I still use Scala whenever I can, but when it comes to performance (cpu limited), I fall back to Java. (I am aware of the compiler plugins of yore and the macros of now that help speed things, and the tree shakers, but they are third-party / require different workflows, and hence I don't feel inclined to use them for certain projects). It is mostly in this space that I am exploring alternatives. Kotlin and Ceylon seem to be more streamlined (conceptually, and hopefully at run-time), but as I haven't actually used them, I am not sure what deficiencies to expect. Edit: Removed a sidenote. Would have been a distraction.
- adriaanm 12y ago
  Thanks for clarifying. I understand your concern. The Scala side of our commercial offering aims to alleviate those worries. Please get in touch if you'd like more details on that.

pron 12y ago

Kotlin and Ceylon are very similar feature-wise, but their ambitions and tradeoffs are completely opposite. Ceylon tries to remake and replace the JDK with new libraries (i.e. modernize everything) while Kotlin has Java interoperability as one of its top priorities, at the expense of some compromises in the language/libraries. I think that Kotlin takes the more pragmatic approach, and introduces much less risk to the project (I use Kotlin and Java classes in the same package, and it's very easy to replace one with the other). So while neither is as mature as Scala (I really don't like Scala but I won't get into that again), Kotlin is as close to risk-free as possible, while Ceylon is more ambitious. It comes down to your personal preference: are you an idealist or a pragmatist (said half jokingly)?

gavinking 12y ago
FTR, Ceylon's Java interop is _excellent_, especially in this latest release, and Ceylon makes it absurdly easy to use the Java SDK directly from Ceylon. Indeed, the Ceylon compiler's Java backend is actually built on Open JDK - that is, it is essentially `javac` itself that generates the bytecode - so we know that the bytecode we generate is extremely close to what Java itself would generate, including full information about generic types that the Java compiler can understand. So, sure, we have the language module, and `ceylon.collection`, `ceylon.locale`, etc, which abstract away from the JVM, but that's necessary, since Ceylon also runs on JavaScript VMs. That _doesn't_ mean you can't easily use `java.lang`, `java.util`, and the rest of the Java SDK if you need it. So it's not quite right to think that Ceylon is lacking in this area. It's actually a strong point of the language.
- pron 12y ago
  I don't think it's lacking (only lacking wrt Kotlin), but that it isn't one of the top two concerns of the language: i.e. it's possible and maybe kind of easy, but certainly not seamless. This might be (and I don't know enough about it, so this is conjecture) one of the reasons why writing Kotlin on Android is pretty simple, while Ceylon not so much. Kotlin also compiles to JavaScript, but it's much more a "hosted" language than one that tries to abstract away the host's native APIs. You're doing great work with Ceylon, I like the type system, and I certainly wouldn't mind a "new JDK" that's as good as the current one minus all the warts that have accumulated over the years, but adopting Ceylon today, I think, is a much bigger risk than adopting Kotlin.