Ask HN: What Happened to Ceylon Language?
I was reading a post about yet another language on HN's front page when I was reminded of Ceylon language which some years back was being promoted as an alternative to Java. I remember seeing it frequently those years but then I stopped following. Now I searched for it and it looks abandoned? The latest news I can find is that it's been donated to Eclipse foundation. What happened?
11 comments
The "better Java" niche was hot during Java's stagnation era (starting 2006 and lasting for almost a decade). The JVM was considered a great runtime, with a stagnant language, and lots of newer languages competed in that niche.
Scala and Clojure, and later Kotlin and others benefited greatly from that niche. The problem for the "better Java" niche was that Java never had to be the best JVM language in order to beat its JVM-based competition in the market. When Java started moving again (Java 8 introduced anonymous functions) and when the release cadence accelerated to every 6 months on 2017, the "Java is stagnant" justification for using other JVM languages lost a lot of traction.
Clojure was never really a "better Java" -- it's a JVM-based Lisp with good Java interop. Scala never leaned too much on the "better Java" niche, and the community is increasingly consolidated around FP. Kotlin still has some "better Java" ambitions, but they also have the Android community at their back. Without Android you would have seen Kotlin trying harder to differentiate itself from Java (EDIT: Google and Kotlin tied the knot in 2017, when Java moved to 6-month release cycle; probably not a coincidence).
Fairly young languages can still see rapid growth -- see Go (1.0 in 2012) and Rust (1.0 in 2015). But you are much less likely to see new languages trying to go head-to-head with Java on the JVM these days.
Scala and Clojure, and later Kotlin and others benefited greatly from that niche. The problem for the "better Java" niche was that Java never had to be the best JVM language in order to beat its JVM-based competition in the market. When Java started moving again (Java 8 introduced anonymous functions) and when the release cadence accelerated to every 6 months on 2017, the "Java is stagnant" justification for using other JVM languages lost a lot of traction.
Clojure was never really a "better Java" -- it's a JVM-based Lisp with good Java interop. Scala never leaned too much on the "better Java" niche, and the community is increasingly consolidated around FP. Kotlin still has some "better Java" ambitions, but they also have the Android community at their back. Without Android you would have seen Kotlin trying harder to differentiate itself from Java (EDIT: Google and Kotlin tied the knot in 2017, when Java moved to 6-month release cycle; probably not a coincidence).
Fairly young languages can still see rapid growth -- see Go (1.0 in 2012) and Rust (1.0 in 2015). But you are much less likely to see new languages trying to go head-to-head with Java on the JVM these days.
There is also the matter that between Clojure (a Lisp), Scala (an ML/FP/fraken-language), Kotlin (multi-paradigm/"modern syntax") there isn't a lot of space for new JVM languages to explore right now unless you were to build something like Pony or Erlang/Elixir that leveraged the new Loom runtime.
Most of the popular paradigms (with Java taking the "C++ alike" role) are already serviced effectively by existing langauges.
Most of the popular paradigms (with Java taking the "C++ alike" role) are already serviced effectively by existing langauges.
Haskell on the JVM is a well-explored niche with lots of working but abandoned projects (Eta, Frege, etc). Getting a JVM backend into GHC would fulfill the "pure/lazy/FP" space, which is notably absent from your list.
Oh that is a good one too. I would actually kind of dig that if one could get off the ground.
Ceylon came out at around the same time as kotlin; for a while they were both good contenders for "a better Java that wasn't too different"
It doesn't seem like the JVM is that great to me; it's so memory-inefficient that it can't be performant except by brute force, and Java's famous lack-of-expressiveness is reflected in the bytecode too.
Of course it does exist and works, so it's mature which is something. But all constants are in memory instead of on disk, no value types, gigantic headers on every object?
C#/.NET is better here.
Of course it does exist and works, so it's mature which is something. But all constants are in memory instead of on disk, no value types, gigantic headers on every object?
C#/.NET is better here.
Do check out the binary-tree benchmark of the benchmark game. You can see how ridiculously ahead of every other managed language Java is when it comes to GC - and while C# and Go can indeed get away with slightly less allocations (until Valhalla happens at least), my experience is that object allocation can’t be that easily avoided in most general purpose applications, and allocation/GC is often the bottleneck at the typical big web application scale. Here Java’s state-of-the-art GC algorithm(s) are pretty much unbeatable.
It is not without reason that FAANG and Fortune500 companies have many/most of their critical web services running on top the JVM (Apple, Google, Amazon, Alibaba, Twitter, etc).
It is not without reason that FAANG and Fortune500 companies have many/most of their critical web services running on top the JVM (Apple, Google, Amazon, Alibaba, Twitter, etc).
You should update your knowledge on this matter. I suggest reading about GrallVM, Loom, Valhalla and many such topics. JVM also has much wider support in terms of management and 3rd party enterprise tooling.
Just to add that Java already is so performant it is often used for HFT! With the technologies/projects you mentioned it’s only going to be better.
I'm aware, but GraalVM isn't "the JVM" (HotSpot) and Valhalla hasn't shipped yet.
(I didn't realize but apparently Valhalla is 8 years old now?)
Apparently it has SIMD now, so that's nice.
(I didn't realize but apparently Valhalla is 8 years old now?)
Apparently it has SIMD now, so that's nice.
It's a JVM that solves a lot of the overhead issues. There are multiple other implementations that can provide a level of scale that's available nowhere else (e.g. Azul).
My point is that the JVM has a huge 3rd party driven ecosystem that's moving at scale. It has very deep backend adoption and has many upcoming projects that will make it even better e.g. project leyden, panama, etc.
My point is that the JVM has a huge 3rd party driven ecosystem that's moving at scale. It has very deep backend adoption and has many upcoming projects that will make it even better e.g. project leyden, panama, etc.
The details are fuzzy in my memory, but as best as I can recall Ceylon was basically created / run by some people from Red Hat / JBoss. They promoted it for a while, but eventually decided to abandon it for some reason. Again, the details are fuzzy, but I think they just decided that other languages that had also some along (maybe Kotlin?) had gotten "good enough" and that Ceylon didn't really have a niche where it was going to be highly in demand. Or something like that. Don't quote me on this, it was all some time ago.
EDIT:
Some bits and pieces of additional info:
https://ceylon-lang.org/blog/2017/08/21/eclipse-ceylon/
https://github.com/eclipse/ceylon/issues/7454
https://news.ycombinator.com/item?id=15057893
EDIT:
Some bits and pieces of additional info:
https://ceylon-lang.org/blog/2017/08/21/eclipse-ceylon/
https://github.com/eclipse/ceylon/issues/7454
https://news.ycombinator.com/item?id=15057893
IIRC, Red Hat got acquired by IBM and the funding evaporated. I think Gavin King works on Quarkus now.
Red Hat definitely got acquired by IBM, but I thought the Ceylon decision happened before that. It's totally possible that I'm wrong on that though.
Ah, you’re right. The team blogged about the move at https://ceylon-lang.org/blog/2017/08/21/eclipse-ceylon/, and they use the present tense when talking about Red Hat
> As you surely know, Red Hat has been the main sponsor of Ceylon over the years, and we're all eternally grateful for this support. It would have been simply impossible to kick-start a project of this scope without the backing of Red Hat. (Full disclosure: we ourselves are employed by Red Hat.)
I had a faulty recollection of this post on the ceylon/dev Gitter https://gitter.im/ceylon/dev?at=5d2765cff5dd14574268bcb3. Funding dried up at Red Hat. Gavin King said that he might try to convince IBM to revive it, but only if he had a clear business case.
> Folks I guess I owe you a bit of a response here, but obviously I have my reasons for not wanting to say too much in public
> As of yesterday I'm an IBM employee which hopefully means that in the medium term there will be more money available for R&D around here, for projects which can make a reasonable case for being worthy of investment in the last couple of years of Red Hat's existence as an independent company, there was essentially no funding available for this kind of project, and Ceylon was a victim of that shortage
> However, obviously, if I'm going to try and convince my fund a new development team for this project, I will have to find a convincing reason to do that, and I will have to think very carefully about what precisely a "next" Ceylon would look like (of course I already have some ideas of mistakes we made, and opportunities that now exist that didn't before, but no clear business case)
> It's probably better if I don't say any more on this topic in this place
> As you surely know, Red Hat has been the main sponsor of Ceylon over the years, and we're all eternally grateful for this support. It would have been simply impossible to kick-start a project of this scope without the backing of Red Hat. (Full disclosure: we ourselves are employed by Red Hat.)
I had a faulty recollection of this post on the ceylon/dev Gitter https://gitter.im/ceylon/dev?at=5d2765cff5dd14574268bcb3. Funding dried up at Red Hat. Gavin King said that he might try to convince IBM to revive it, but only if he had a clear business case.
> Folks I guess I owe you a bit of a response here, but obviously I have my reasons for not wanting to say too much in public
> As of yesterday I'm an IBM employee which hopefully means that in the medium term there will be more money available for R&D around here, for projects which can make a reasonable case for being worthy of investment in the last couple of years of Red Hat's existence as an independent company, there was essentially no funding available for this kind of project, and Ceylon was a victim of that shortage
> However, obviously, if I'm going to try and convince my fund a new development team for this project, I will have to find a convincing reason to do that, and I will have to think very carefully about what precisely a "next" Ceylon would look like (of course I already have some ideas of mistakes we made, and opportunities that now exist that didn't before, but no clear business case)
> It's probably better if I don't say any more on this topic in this place
I frequently wish I had Ceylon's union + intersection types in Java. Typescript has them, but they aren't as rigorous. Also the collection classes were rethought and designed with immutability in mind (reading a list is a different interface from mutating a list).
Honestly, it was/is a pretty great language.
I think their biggest mistake was picking Eclipse as the IDE. They eventually produced an IntelliJ plugin but it was far too late. The serious JVM dev community had already picked IntelliJ. I don't know anyone who uses Eclipse anymore.
Honestly, it was/is a pretty great language.
I think their biggest mistake was picking Eclipse as the IDE. They eventually produced an IntelliJ plugin but it was far too late. The serious JVM dev community had already picked IntelliJ. I don't know anyone who uses Eclipse anymore.
wasn't it coz Eclipse team was working on Ceylon? also Scala3 has the union + intersection types
It really looks abandoned. On this page [0] there is a list of leaders and commiters. Stéphane Épardaud is on Twitter [1], as well as Gavin King [2]. I will ask them.
[0] https://projects.eclipse.org/proposals/eclipse-ceylon
[1] https://twitter.com/unfromage
[2] https://twitter.com/1ovthafew
[0] https://projects.eclipse.org/proposals/eclipse-ceylon
[1] https://twitter.com/unfromage
[2] https://twitter.com/1ovthafew
This should tell you about the current status (which I interpret as "it's dead"): https://github.com/eclipse/ceylon/issues/7454
My impression was that it wasn’t getting much traction and thus was abandoned at some point. It was a nice “better Java”, but it didn’t have any compelling killer features and also not a lot of marketing behind it.
My feeling is that the timing of trends in development at the time made Ceylon less attractive than it might have been based on its merits.
I remember Ceylon being touted as a general purpose language that could target the web as well as the backend.
I remember Ceylon being touted as a general purpose language that could target the web as well as the backend.
* node.js - 2009
* Ceylon - 2011Ceylon was designed to run as well on the JVM as on JavaScript... there was even a community member who for some reason got really far into making it run on the Dart VM.
It was a great language, with awesome features we still don't see in a lot of languages (the way tuples were deeply integrated into the language such that function arguments were treated as tuples, nullable types were just unions Null|T, the advanced module system, type-safe reflection which enabled stuff like type-safe keypaths which someone posted for Rust the other day, were all brilliant included in Ceylon).
However, the execution was not great. There were bugs, there was no killer app/framework for it, the focus was too much on the ideas.
I am quite upset it basically lost completely to Kotlin (and maybe Scala)... I invested a good deal of time learning it and that turned out to be mostly wasted time, except for a few design approaches and ideas that stick with me and can be transferred nicely to less powerful languages.
It was a great language, with awesome features we still don't see in a lot of languages (the way tuples were deeply integrated into the language such that function arguments were treated as tuples, nullable types were just unions Null|T, the advanced module system, type-safe reflection which enabled stuff like type-safe keypaths which someone posted for Rust the other day, were all brilliant included in Ceylon).
However, the execution was not great. There were bugs, there was no killer app/framework for it, the focus was too much on the ideas.
I am quite upset it basically lost completely to Kotlin (and maybe Scala)... I invested a good deal of time learning it and that turned out to be mostly wasted time, except for a few design approaches and ideas that stick with me and can be transferred nicely to less powerful languages.
It was essentially killed during Google I/O (May 2017) when Google announced that it would add Kotlin as an official programming language for Android development. This gave Kotlin a huge boost in visibility at a time when a number of languages including Ceylon were competing as alternative JVM-languages. RedHat understood that and a few months later it was announced that Ceylon was being donated to Eclipse which was a euphemistic way of saying it was now abandonware.
It's too bad because I personally preferred Ceylon over Kotlin.
It's too bad because I personally preferred Ceylon over Kotlin.
It's called Sri Lanka now.
Any references to its documentation?
It is a surprisingly good landing page for an unfortunately dead language.
[deleted]
Kotlin killed it, espceially with Google picking it for Android. I remember looking at it and it had some weird stuff and I liked Kotlin better, and Groovy was going strong.
Kotlin is a "better java" from a footgun/safety + syntax perspective, and better than Ceylon in most features and ways. So it won that war. And here is another bad idea, from Ceylon's wikipedia:
"Modularity built into the language, based on JBoss modules, interoperable with OSGi[10] and Maven[11]"
Yikes. Three very-obsolete parts of the java ecosystem, and divisive in the ecosystem community at the time of their introduction/use. Not a good strategy.
Groovy was a "better java" with lots of footguns and more-than-one-way and lots of cool features. So it won the scala/whomever war because it was a path for ruby and python people and paradigms. Most JVM evolution has been adopting groovy language features. Not that groovy did them in a revolutionary way, it just had them a lot earlier. But groovy is fading steadily as the JVM adopts its killer features. Groovy is my main programming language on the JVM.
Clojure has the inherent problems of Lisps for popularity, and Scala was possibly the most complicated language every designed. Great for the top 1% of programmers, but oh well for mainstream success.
Kotlin is a "better java" from a footgun/safety + syntax perspective, and better than Ceylon in most features and ways. So it won that war. And here is another bad idea, from Ceylon's wikipedia:
"Modularity built into the language, based on JBoss modules, interoperable with OSGi[10] and Maven[11]"
Yikes. Three very-obsolete parts of the java ecosystem, and divisive in the ecosystem community at the time of their introduction/use. Not a good strategy.
Groovy was a "better java" with lots of footguns and more-than-one-way and lots of cool features. So it won the scala/whomever war because it was a path for ruby and python people and paradigms. Most JVM evolution has been adopting groovy language features. Not that groovy did them in a revolutionary way, it just had them a lot earlier. But groovy is fading steadily as the JVM adopts its killer features. Groovy is my main programming language on the JVM.
Clojure has the inherent problems of Lisps for popularity, and Scala was possibly the most complicated language every designed. Great for the top 1% of programmers, but oh well for mainstream success.
I really don’t buy this Scala complicated myth. It is a very small language, which is very expressive and has very powerful features. But it is not a complicated language, which I would leave for Rust and C++ having many features instead. Kotlin seems to have more features in-built than Scala even. Scala chooses more powerful features that incorporate the functionality of many.