4 ms·

Props to https://ceylon-lang.org/ https://ceylon-lang.org/ for a good effort. It doesn't seem to be on the race anymore, but at the time it looked like a super

Props to https://ceylon-lang.org/ https://ceylon-lang.org/ for a good effort. It doesn't seem to be on the race anymore, but at the time it looked like a super interesting contender.

imtringued 7y ago
It was a good example of how to build a language in 4 years but the JVM language space is already filled to the brim. The only way to stand out is by having a large vendor bless it (Kotlin on Android).
- thu2111 7y ago
  I'm not sure that's the whole story. Kotlin was blessed on Android because it was growing like a weed, developers didn't need Google's permission to use it and weren't asking for it. The Android team went with the flow (smartly). I evaluated Ceylon vs Kotlin in 2015, back when Kotlin wasn't even close to a 1.0 release and neither had any adoption. They're very similar in a lot of ways and so the choice came down to a lot of small things added up rather than any one big thing. I chose Kotlin for a lot of reasons, but a few (in no particular order) were: 1. It had a more convenient syntax. The Ceylon designer felt that autocomplete meant verbose syntax didn't matter but it does. "variable Integer foo = 10" isn't just a typing issue but also a reading issue. "var foo = 10" is better. 2. Ceylon deviated more from the JVM ecosystem than Kotlin, in particular, it invented its own collections like Scala, but which didn't appear to be much different to regular Java collections. This means idiomatic Ceylon would obviously be a Ceylon library to users and not a Java library. Kotlin uses standard Java collections but enhanced via extension methods. It also provides a bunch of knobs to make the output classes seem like idiomatic Java classes in the few places that doesn't happen automatically, so you can reasonably use it for libraries. This makes a huge difference to Java interop. Kotlin is really the only JVM language that takes Java interop seriously: the rest all treat it as a price of admission to use the JVM at all and minimise their effort on it. 3. Ceylon was mostly tooled for Eclipse which, in my view, is an inferior IDE to IntelliJ. The tooling was itself not as good as even the pre-1.0 Kotlin plugin. 4. Ceylon had invested heavily in a complicated module and type system, which was the primary set of things they emphasised. These sorts of features have a relatively poor track record of delivering value; slightly-stronger-than-Java seems to be about the sweet spot at the moment. Much stronger than that and you end up in Haskell. Kotlin went in for more type inference and more usable generics (convenience), Ceylon 5. Ceylon seemed much riskier to me (correctly). Nothing used it. It was clearly the project of one guy at Red Hat who'd had a previous successful project (Hibernate), but Red Hat weren't talking about it or using it in any way. On the other hand JetBrains had a large team assigned to Kotlin and were explicit that they were creating it to use in IntelliJ itself. The existence of a Java to Kotlin converter tool showed that they were completely serious about this, as J2K was a lot of work to build and would only be useful in a truly serious assault on existing Java codebases. Ceylon seemed far more interested in fancy type systems than the practical details of adoption. 6. Ceylon had some weird gotchas and interop glitches that weren't normal for Java-like languages, like a sensitivity to the case of the first letter of identifiers (I know Go does this too) and difficulty handling Java arrays. There are named constructors (cool) which don't compile to static methods as is idiomatic for Java but some weird Ceylon specific notation (boo). This sort of thing showed it wasn't trying to be "just a better Java" which is what I was in the market for.
  - emmanueloga_ 7y ago
    Wow, thanks for the analysis! I think it was very astute to pay attention to how Red Hat was supporting (or not) the language, it never occurred to me to look at the project from that POV, a really useful one. I think the language is quirky in a lot of ways with the verbose syntax being one of them. I liked some aspects of the type system that made it look close to an ML flavor, although the language had heavy OOP syntax. In this way I thought it was similar to Scala. There are a few nice write ups from the author on the process of coming up with the syntax. The one talking about constructors is a good example [1]. 1: https://ceylon-lang.org/blog/2015/06/21/constructors/ https://ceylon-lang.org/blog/2015/06/21/constructors/

Props to https://ceylon-lang.org/ https://ceylon-lang.org/ for a good effort. It doesn't seem to be on the race anymore, but at the time it looked like a super interesting contender.

imtringued 7y ago

It was a good example of how to build a language in 4 years but the JVM language space is already filled to the brim. The only way to stand out is by having a large vendor bless it (Kotlin on Android).

thu2111 7y ago
I'm not sure that's the whole story. Kotlin was blessed on Android because it was growing like a weed, developers didn't need Google's permission to use it and weren't asking for it. The Android team went with the flow (smartly). I evaluated Ceylon vs Kotlin in 2015, back when Kotlin wasn't even close to a 1.0 release and neither had any adoption. They're very similar in a lot of ways and so the choice came down to a lot of small things added up rather than any one big thing. I chose Kotlin for a lot of reasons, but a few (in no particular order) were: 1. It had a more convenient syntax. The Ceylon designer felt that autocomplete meant verbose syntax didn't matter but it does. "variable Integer foo = 10" isn't just a typing issue but also a reading issue. "var foo = 10" is better. 2. Ceylon deviated more from the JVM ecosystem than Kotlin, in particular, it invented its own collections like Scala, but which didn't appear to be much different to regular Java collections. This means idiomatic Ceylon would obviously be a Ceylon library to users and not a Java library. Kotlin uses standard Java collections but enhanced via extension methods. It also provides a bunch of knobs to make the output classes seem like idiomatic Java classes in the few places that doesn't happen automatically, so you can reasonably use it for libraries. This makes a huge difference to Java interop. Kotlin is really the only JVM language that takes Java interop seriously: the rest all treat it as a price of admission to use the JVM at all and minimise their effort on it. 3. Ceylon was mostly tooled for Eclipse which, in my view, is an inferior IDE to IntelliJ. The tooling was itself not as good as even the pre-1.0 Kotlin plugin. 4. Ceylon had invested heavily in a complicated module and type system, which was the primary set of things they emphasised. These sorts of features have a relatively poor track record of delivering value; slightly-stronger-than-Java seems to be about the sweet spot at the moment. Much stronger than that and you end up in Haskell. Kotlin went in for more type inference and more usable generics (convenience), Ceylon 5. Ceylon seemed much riskier to me (correctly). Nothing used it. It was clearly the project of one guy at Red Hat who'd had a previous successful project (Hibernate), but Red Hat weren't talking about it or using it in any way. On the other hand JetBrains had a large team assigned to Kotlin and were explicit that they were creating it to use in IntelliJ itself. The existence of a Java to Kotlin converter tool showed that they were completely serious about this, as J2K was a lot of work to build and would only be useful in a truly serious assault on existing Java codebases. Ceylon seemed far more interested in fancy type systems than the practical details of adoption. 6. Ceylon had some weird gotchas and interop glitches that weren't normal for Java-like languages, like a sensitivity to the case of the first letter of identifiers (I know Go does this too) and difficulty handling Java arrays. There are named constructors (cool) which don't compile to static methods as is idiomatic for Java but some weird Ceylon specific notation (boo). This sort of thing showed it wasn't trying to be "just a better Java" which is what I was in the market for.
- emmanueloga_ 7y ago
  Wow, thanks for the analysis! I think it was very astute to pay attention to how Red Hat was supporting (or not) the language, it never occurred to me to look at the project from that POV, a really useful one. I think the language is quirky in a lot of ways with the verbose syntax being one of them. I liked some aspects of the type system that made it look close to an ML flavor, although the language had heavy OOP syntax. In this way I thought it was similar to Scala. There are a few nice write ups from the author on the process of coming up with the syntax. The one talking about constructors is a good example [1]. 1: https://ceylon-lang.org/blog/2015/06/21/constructors/ https://ceylon-lang.org/blog/2015/06/21/constructors/