4 ms·

Ceylon has a potentional to become the best statically typed language available. I really love the elegance combined with the pragmatic focus on readability, to

Ceylon has a potentional to become the best statically typed language available. I really love the elegance combined with the pragmatic focus on readability, toolability and type-safety. Ceylon is so refreshing compared to Scala. Unfortunately it didn't get a lot of attention on HN, I'm quite curious what other people's impressions are.

pron 13y ago
Ceylon is very similar to Kotlin, but I much prefer Kotlin, mostly because it so seamlessly interoperates with Java (more so than any other JVM language I'm aware of). Also, Kotlin already has kickass IDE support.
- RivieraKid 13y ago
  Agree that Kotlin has slightly better interoperability and IDE support (but Ceylon is interoperable with Java too and has an Eclipse-based IDE). But I like Ceylon more because: * Union and intersection types. * I find the type system cleaner and more elegant. * It's an attempt to build a whole new platform with a new SDK. Kotlin is, in a way, just a syntax skin over the Java platform. * Reified generics. Kotlin got rid of them. * I personally find Ceylon's "String str" more readable than Kotlin's "str: String". * Type-safe metaprogramming. * Comprehensions (not 100% sure Kotlin doesn't have them). * It's compilable to JS. * Slightly more regular syntax, more readable generic declarations, better web documentation, currying, spread operator, etc.
  - timclark 13y ago
    Some of the smaller decisions the Ceylon team has made also seem nicer than the Kotlin equivalent. For example I prefer the Ceylon "if(exists x) {}" to the Kotlin "if(x != null)" - even though the Ceylon is further from the Java syntax.
  - pron 13y ago
    Kotlin also compiles to JS and has typesafe Groovy-style builders. I don't like the union and intersection types, and think Kotlin being "a syntax skin over the Java platform" is its main advantage. Thing is, neither Kotlin nor Ceylon (nor Scala, IMO) add something fundamentally necessary over what's available in Java (8). They mostly provide productivity enhancements. For me, added productivity is really nice, but it doesn't justify switching a language, unless it's a 10x productivity boost (Clojure is different; it provides a whole new way of thinking and managing state and data, which is very important for concurrency - this is big). So in that case, I'd rather give Java a facelift than change to something else altogether. Kotlin is just a Java facelift. It's trivial and transparent to mix Kotlin and Java classes, even in the same package.
    - RivieraKid 13y ago
      Productivity and how fun is it to use a language are about the only metrics that I care about. Even small productivity increase can be a reason to switch language. I don't understand the Clojure bit - do you mean STM?
      - pron 13y ago
        Well, I'm used to developing multi-MLOC projects in large teams; they don't switch a language so easily... As for Clojure, I mean this: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey http://www.infoq.com/presentations/Value-Identity-State-Rich... (basically: immutability, controlled state transitions via agents/atomic/STM)
      - pjmlp 13y ago
        My metrics are the technology stack the customer requested and if the application/library does what was requested.
  - trailfox 13y ago
    I happen to find str: String much more readable than String str.
- timclark 13y ago
  Kotlin is a very nice replacement for Java but I really like the ambition and thought being shown by the Ceylon development team. I sure do hope that they get an IntelliJ plugin completed sometime in the future.
  - pron 13y ago
    I can't see the purpose. See my comment here: https://news.ycombinator.com/item?id=6846319 https://news.ycombinator.com/item?id=6846319
- lmm 13y ago
  I thought Kotlin didn't have existential types? Which means it won't be able to offer full compatibility with Java generic types like Scala does.
- gavinking 13y ago
  > Also, Kotlin already has kickass IDE support. _Please_ try Ceylon IDE, and let us know where it's nonasskicking. We've worked very, very hard on it, and we think we have something really useful and usable, but of course we very much welcome feedback. FTR, I personally pushed almost 240 klocs to this project over the past two years.
  - yareally 13y ago
    For some of us, it comes down to whether we prefer Intellij or Eclipse. Having used both for a number of years, I prefer the former over the later (though for reasons that would be outside the scope of the Kotlin or Ceylon Plugins themselves).
    - gavinking 13y ago
      Ah, OK, fair enough, well, Bastien and Matija have recently been making very good progress on the IntelliJ plugin for Ceylon, and since we expect to be able to reuse quite a bit of underlying code from the Eclipse plugin, we hope to something useful quite soon. Stay tuned :)
codygman 13y ago
Best available is a pretty bold claim, how does it compare to the likes of Haskell in regards to static typing, type safety, and readability?
- RivieraKid 13y ago
  I have very little experience with Haskell, I didn't really like it, it didn't seem to have strong focus on peoductivity, my view is that: * Imperative programming is more straightforward in Ceylon. * The same holds for functions with side-effects. * Type safety is similar, Ceylon currently doesn't have type classes and generalized algebraic data types but will be probably added according to the FAQ. * Ceylon is less type-inferred, which makes it more readable IMHO (1. regular syntax 2. type annotations are not just for the compiler, but for documentation too). Also - less confusing compiler errors. * In general, Ceylon feels pragmatic, Haskell academic.
  - pjmlp 13y ago
    > In general, Ceylon feels pragmatic, Haskell academic. Except Haskell is being used in the industry already, while Ceylon is a Java wannabe replacement.
    - RivieraKid 13y ago
      Haskell is way older than Ceylon.
  - codygman 13y ago
    > * The same holds for functions with side-effects. Just about every haskell program I write has functions with side-effects. > * Ceylon is less type-inferred, which makes it more readable IMHO ... 2. type annotations are not just for the compiler, but for documentation too). So having to write type annotations all the time is an advantage for you? You can just as easily add type annotations to Haskell, are you saying that since it is compiler enforced with Ceylon, that Ceylon code as a whole is easier to read? Furthermore, doesn't less type-inferred just mean "type inference isn't as good", or was that a design decision? > Also - less confusing compiler errors. Any examples of confusing Haskell compiler errors? I personally haven't seen any memorably confusing compiler errors from Haskell. Have you seen any with Haskell or is that just something you've heard about? Any examples of compiler errors where Ceylon beats Haskell? Any examples of compiler errors where Ceylon beats Java? > 1. regular syntax By "regular syntax" do you mean "algol derived or inspired"? > * In general, Ceylon feels pragmatic, Haskell academic. This is interesting, because it's something I've heard from just about everyone I've asked about Haskell. Recently I have delved into Haskell myself and haven't found it true. For instance, arrows are something many consider "academic", but they enable the very pragmatic and real world advantage of handling HTML like: -- haskell -- added bonus of type safety through type inference! images tree = tree >>> css "img" >>> getAttrValue "src" -- python def images(tree): imgs = [elem for elem in tree if elem.tag == "img"] sources = [img.get('src') for img in imgs] return sources -- alternate python def images(tree): return [ img.get('src' for img in filter(lambda i: i.tag == "img", tree)] If my understanding is correct the Haskell above is (at least could) take advantage of stream fusion which has the real world advantage of being really efficient and really fast. > * In general, Ceylon feels pragmatic, Haskell academic. This is something that is entirely subjective. I will have to look into Ceylon more in the future. I will say that from the outside Haskell looked very academic for me, but after writing some code, Haskell feels/seems to be/has proven to be a very pragmatic language that doesn't deserve a reputation of being "academic". As a whole I wish that many other languages weren't just dismissed as "academic" so that we could innovate more quickly and improve technology as a whole. There are valid arguments to be had about much of the experimental stuff, but calling something "academic" is usually a cop out in my experience.

pron 13y ago

Ceylon is very similar to Kotlin, but I much prefer Kotlin, mostly because it so seamlessly interoperates with Java (more so than any other JVM language I'm aware of). Also, Kotlin already has kickass IDE support.

RivieraKid 13y ago
Agree that Kotlin has slightly better interoperability and IDE support (but Ceylon is interoperable with Java too and has an Eclipse-based IDE). But I like Ceylon more because: * Union and intersection types. * I find the type system cleaner and more elegant. * It's an attempt to build a whole new platform with a new SDK. Kotlin is, in a way, just a syntax skin over the Java platform. * Reified generics. Kotlin got rid of them. * I personally find Ceylon's "String str" more readable than Kotlin's "str: String". * Type-safe metaprogramming. * Comprehensions (not 100% sure Kotlin doesn't have them). * It's compilable to JS. * Slightly more regular syntax, more readable generic declarations, better web documentation, currying, spread operator, etc.
- timclark 13y ago
  Some of the smaller decisions the Ceylon team has made also seem nicer than the Kotlin equivalent. For example I prefer the Ceylon "if(exists x) {}" to the Kotlin "if(x != null)" - even though the Ceylon is further from the Java syntax.
- pron 13y ago
  Kotlin also compiles to JS and has typesafe Groovy-style builders. I don't like the union and intersection types, and think Kotlin being "a syntax skin over the Java platform" is its main advantage. Thing is, neither Kotlin nor Ceylon (nor Scala, IMO) add something fundamentally necessary over what's available in Java (8). They mostly provide productivity enhancements. For me, added productivity is really nice, but it doesn't justify switching a language, unless it's a 10x productivity boost (Clojure is different; it provides a whole new way of thinking and managing state and data, which is very important for concurrency - this is big). So in that case, I'd rather give Java a facelift than change to something else altogether. Kotlin is just a Java facelift. It's trivial and transparent to mix Kotlin and Java classes, even in the same package.
  - RivieraKid 13y ago
    Productivity and how fun is it to use a language are about the only metrics that I care about. Even small productivity increase can be a reason to switch language. I don't understand the Clojure bit - do you mean STM?
    - pron 13y ago
      Well, I'm used to developing multi-MLOC projects in large teams; they don't switch a language so easily... As for Clojure, I mean this: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey http://www.infoq.com/presentations/Value-Identity-State-Rich... (basically: immutability, controlled state transitions via agents/atomic/STM)
    - pjmlp 13y ago
      My metrics are the technology stack the customer requested and if the application/library does what was requested.
- trailfox 13y ago
  I happen to find str: String much more readable than String str.
timclark 13y ago
Kotlin is a very nice replacement for Java but I really like the ambition and thought being shown by the Ceylon development team. I sure do hope that they get an IntelliJ plugin completed sometime in the future.
- pron 13y ago
  I can't see the purpose. See my comment here: https://news.ycombinator.com/item?id=6846319 https://news.ycombinator.com/item?id=6846319
lmm 13y ago
I thought Kotlin didn't have existential types? Which means it won't be able to offer full compatibility with Java generic types like Scala does.
gavinking 13y ago
> Also, Kotlin already has kickass IDE support. _Please_ try Ceylon IDE, and let us know where it's nonasskicking. We've worked very, very hard on it, and we think we have something really useful and usable, but of course we very much welcome feedback. FTR, I personally pushed almost 240 klocs to this project over the past two years.
- yareally 13y ago
  For some of us, it comes down to whether we prefer Intellij or Eclipse. Having used both for a number of years, I prefer the former over the later (though for reasons that would be outside the scope of the Kotlin or Ceylon Plugins themselves).
  - gavinking 13y ago
    Ah, OK, fair enough, well, Bastien and Matija have recently been making very good progress on the IntelliJ plugin for Ceylon, and since we expect to be able to reuse quite a bit of underlying code from the Eclipse plugin, we hope to something useful quite soon. Stay tuned :)

codygman 13y ago

Best available is a pretty bold claim, how does it compare to the likes of Haskell in regards to static typing, type safety, and readability?

RivieraKid 13y ago
I have very little experience with Haskell, I didn't really like it, it didn't seem to have strong focus on peoductivity, my view is that: * Imperative programming is more straightforward in Ceylon. * The same holds for functions with side-effects. * Type safety is similar, Ceylon currently doesn't have type classes and generalized algebraic data types but will be probably added according to the FAQ. * Ceylon is less type-inferred, which makes it more readable IMHO (1. regular syntax 2. type annotations are not just for the compiler, but for documentation too). Also - less confusing compiler errors. * In general, Ceylon feels pragmatic, Haskell academic.
- pjmlp 13y ago
  > In general, Ceylon feels pragmatic, Haskell academic. Except Haskell is being used in the industry already, while Ceylon is a Java wannabe replacement.
  - RivieraKid 13y ago
    Haskell is way older than Ceylon.
- codygman 13y ago
  > * The same holds for functions with side-effects. Just about every haskell program I write has functions with side-effects. > * Ceylon is less type-inferred, which makes it more readable IMHO ... 2. type annotations are not just for the compiler, but for documentation too). So having to write type annotations all the time is an advantage for you? You can just as easily add type annotations to Haskell, are you saying that since it is compiler enforced with Ceylon, that Ceylon code as a whole is easier to read? Furthermore, doesn't less type-inferred just mean "type inference isn't as good", or was that a design decision? > Also - less confusing compiler errors. Any examples of confusing Haskell compiler errors? I personally haven't seen any memorably confusing compiler errors from Haskell. Have you seen any with Haskell or is that just something you've heard about? Any examples of compiler errors where Ceylon beats Haskell? Any examples of compiler errors where Ceylon beats Java? > 1. regular syntax By "regular syntax" do you mean "algol derived or inspired"? > * In general, Ceylon feels pragmatic, Haskell academic. This is interesting, because it's something I've heard from just about everyone I've asked about Haskell. Recently I have delved into Haskell myself and haven't found it true. For instance, arrows are something many consider "academic", but they enable the very pragmatic and real world advantage of handling HTML like: -- haskell -- added bonus of type safety through type inference! images tree = tree >>> css "img" >>> getAttrValue "src" -- python def images(tree): imgs = [elem for elem in tree if elem.tag == "img"] sources = [img.get('src') for img in imgs] return sources -- alternate python def images(tree): return [ img.get('src' for img in filter(lambda i: i.tag == "img", tree)] If my understanding is correct the Haskell above is (at least could) take advantage of stream fusion which has the real world advantage of being really efficient and really fast. > * In general, Ceylon feels pragmatic, Haskell academic. This is something that is entirely subjective. I will have to look into Ceylon more in the future. I will say that from the outside Haskell looked very academic for me, but after writing some code, Haskell feels/seems to be/has proven to be a very pragmatic language that doesn't deserve a reputation of being "academic". As a whole I wish that many other languages weren't just dismissed as "academic" so that we could innovate more quickly and improve technology as a whole. There are valid arguments to be had about much of the experimental stuff, but calling something "academic" is usually a cop out in my experience.