7 ms·

Ceylon 1.1.0 is now available

60 points by bilalhusain 12y ago

kolev 12y ago
This is great news and it should (finally!) work on JDK8 although it won't have JDK8-specific optimizations, which is a pity - as far as I remember, it's planned for v1.2, which probably be out when JDK9 is out, too. I personally would like faster catchup time with the latest JDK, especially when previews are available in advance. Kudos to Groovy that release JDK8-optimized version pretty quickly!
- gavinking 12y ago
  Yes, that's right, to confirm, it does run on Java 8, but we don't yet take advantage of any Java 8 features of the VM. (We first need to rebase the compiler backend on the Java 8 compiler, which could take some work.) FTR, we hope to move to a faster release cycle, 10 months between releases is really far too long.
  - fithisux 12y ago
    I any case congratulations for the release. I am eager to take it for a ride.
    - kolev 12y ago
      Me, too. I'm checking every few minutes to see if Homebrew has the update. :D
      - gavinking 12y ago
        It's there now, I believe.
        kolev 12y ago
        Yes it is, Gavin. And thanks for the great job you're doing with Ceylon!
        gavinking 12y ago
        Cheers!
  - kolev 12y ago
    Great to hear about the more rapid release cycle - it will help the switch to Ceylon!
- vorg 12y ago
  > Kudos to Groovy that release JDK8-optimized version pretty quickly! Do note from the http://groovy.codehaus.org/Groovy+2.3+release+notes http://groovy.codehaus.org/Groovy+2.3+release+notes that the "JDK 8 and its interface default methods introduced some incompatibilities with a few methods of the Groovy Development Kit, so we had to adapt to the situation, introducing minor breaking changes for the affected methods and their outcome." Also note the "Breaking changes" list hidden at the bottom of that page, which probably only lists some of them.
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.
atmosx 12y ago
Can someone with technical background explain me how does this language compare to Rust? The syntax looks way easier to me (I'm familiar with ruby) than Rust, but are there any use cases where Ceylon targets over Rust and vice-versa? EDIT: NM, the one is for systems programming (Rust) the other one is for high-level OOP (web-based apps, gui, etc.)
- m0th87 12y ago
  I don't know Ceylon, but because it targets JVM/JS VMs, it's not suitable as a systems programming language - which Rust is especially useful for.
  - gavinking 12y ago
    That's exactly right. Ceylon and Rust are both new languages, with, it seems to me, a fair amount of similarity in terms of overall philosophy, but they target quite distinct usecases. Ceylon -> VMs, Rust -> systems programming. And so quite fundamental differences between the languages arise out of that.

60 points by bilalhusain 12y ago

kolev 12y ago

This is great news and it should (finally!) work on JDK8 although it won't have JDK8-specific optimizations, which is a pity - as far as I remember, it's planned for v1.2, which probably be out when JDK9 is out, too. I personally would like faster catchup time with the latest JDK, especially when previews are available in advance. Kudos to Groovy that release JDK8-optimized version pretty quickly!

gavinking 12y ago
Yes, that's right, to confirm, it does run on Java 8, but we don't yet take advantage of any Java 8 features of the VM. (We first need to rebase the compiler backend on the Java 8 compiler, which could take some work.) FTR, we hope to move to a faster release cycle, 10 months between releases is really far too long.
- fithisux 12y ago
  I any case congratulations for the release. I am eager to take it for a ride.
  - kolev 12y ago
    Me, too. I'm checking every few minutes to see if Homebrew has the update. :D
    - gavinking 12y ago
      It's there now, I believe.
      - kolev 12y ago
        Yes it is, Gavin. And thanks for the great job you're doing with Ceylon!
        gavinking 12y ago
        Cheers!
- kolev 12y ago
  Great to hear about the more rapid release cycle - it will help the switch to Ceylon!
vorg 12y ago
> Kudos to Groovy that release JDK8-optimized version pretty quickly! Do note from the http://groovy.codehaus.org/Groovy+2.3+release+notes http://groovy.codehaus.org/Groovy+2.3+release+notes that the "JDK 8 and its interface default methods introduced some incompatibilities with a few methods of the Groovy Development Kit, so we had to adapt to the situation, introducing minor breaking changes for the affected methods and their outcome." Also note the "Breaking changes" list hidden at the bottom of that page, which probably only lists some of them.

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.

atmosx 12y ago

Can someone with technical background explain me how does this language compare to Rust? The syntax looks way easier to me (I'm familiar with ruby) than Rust, but are there any use cases where Ceylon targets over Rust and vice-versa? EDIT: NM, the one is for systems programming (Rust) the other one is for high-level OOP (web-based apps, gui, etc.)

m0th87 12y ago
I don't know Ceylon, but because it targets JVM/JS VMs, it's not suitable as a systems programming language - which Rust is especially useful for.
- gavinking 12y ago
  That's exactly right. Ceylon and Rust are both new languages, with, it seems to me, a fair amount of similarity in terms of overall philosophy, but they target quite distinct usecases. Ceylon -> VMs, Rust -> systems programming. And so quite fundamental differences between the languages arise out of that.