Is this project dead?

[ePaul]

When my engineering team at the company I work for recently discussed which programming language to use for future projects, I brought Ceylon onto the table (other candidates were Kotlin, Scala, Java). But my proposal was "shot down" with the argument that it's only in maintenance mode since 2017.

Looking at the activity here, it actually looks like not much happened after Ceylon was handed over from Red Hat to the Eclipse foundation – so actually it looks like not even maintenance is happening. The IntelliJ plugin doesn't work properly with recent IntelliJ versions either.

While the handover to Eclipse was explained as this way people will see it as more neutral than when it's just backed by Red Hat and "Eclipse Ceylon has a great future at the Eclipse Foundation!", it now looks more like Red Hat didn't want to pay people working on this anymore, and used the handover as an excuse to stop doing so.

Is there actually anyone left maintaining Ceylon and the surrounding projects?

(Sorry if this sounds mean, I don't intend to attack anyone, just trying to find out what's the state.)

[momomo]

lol, by the silence of it i think we got our answer :(

[Voiteh]

Actually I'm trying to make release of 1.4.0 but help of community would be really appreciated...

[momomo]

holy shit votieh, you guys should be more vocal about this. the fact that i've been asking the same question for the past 1.5 years because of refusal to use kotlin because i know this is better but due to lack of answers i decided it was not worth going into, not knowing the project is still active. if it is active then that changes things.

I am not sure what I can do to help, I am not a compiler guy but I can try if you have specifics.

[momomo]

Let us kick up a storm: https://www.reddit.com/r/ceylon/

[Voiteh]

Project is "active-ish". Only by community we may make it active. If You would like to help there is dev channel on gitter where we discuss. https://gitter.im/ceylon/dev . There is still some work to do. We need to find out what actually needs to be included into 1.4.0 release. Language, SDK, intellij, eclipse. There is a load of projects to be handled.

[thinker3]

ceylon is good, but need a rich daddy

[orochi02]

honestly i think it is good that even with how close to death ceylon is, that it is still alive cause from what i heard it has really nice potential and i really am looking forward to future development of ceylon. but i gotta say: people thinking this language is dead, does not really help the community thrive. you gotta make it clear that ceylon is not dead

[msx80]

i'd really love to see Ceylon resume development. I think it's the best language.

[kinegg]

Let Ceylon die, it's a waste of time reviving it at this point. Other languages and frameworks have picked up the good parts a long time ago, while ignoring the bad parts which are now just cruft (like the invasive module system that made interop and tooling a nightmare... this is why Kotlin succeeded in the JVM space: it doesn't suppose a whole non-language environment)

RedHat and the Ceylon team pulled the rug under quite a few community members when they transitioned the project to Eclipse, fully aware that none of the core members would continue working on it since RH pulled funding... without communicating this fact to the community. Instead they did the usual death rattle marketing thing:

We believe that joining the Eclipse Community will help Ceylon become even more popular with contributors and users alike.

... knowing that no core developer would touch the code again, which was actually a bit of a mess and nearly impossible for others to pick up. One or two guys tried, but now they're gone as well. Instead of becoming "even more popular with contributors and users alike", it immediately grinded to a halt.

Ceylon came with some good ideas, but ended up being too complex, too verbose, too anal about modules and with a code base that everybody secretly hated (people were willing to work on it only if funded, and that's a good sign it's not a well driven open source project)

RIP

[momomo]

I don't think there are many languages that can compete as of yet, the generic stuff is just not there in any JVM language I know of. I think the Javascript interop was the biggest mistake and likely time waster. Who the hell writes java, kotlin or ceylon code to compile to JS? Only the most horbid developer would do that. I can not imagine the complexity trying to translate complex stuff, such as sets, generics and what not to Javascript.

If you picked Ceylon as a language / tool, then surely you are top dog anyway. Top dogs would want to be in control and hence write their own Javascript to remain as true and flexible as possible. I am pretty sure of all the ceylon adopters out there, ZERO person ever used it for Javascript, yet that part must have been a major undertaking.

If our company ever becomes rich enough, we'll hire king and fund a new language, but yes, I think this is dead too at this point.

[kinegg]

I don't think there are many languages that can compete as of yet, the generic stuff is just not there in any JVM language I know of

Well the advanced generic capabilities is not terribly important as it's mostly a convenience to standard library writers. Look at Java... it has pretty basic generics but 99.9% of programmers only use a fraction of what they can do, namely pass types to containers. Advanced generics was never enough to win the masses. Again, Kotlin made better pragmatic decisions and their generics implementation solved the problems most people encountered in Java.

[momomo]

I am not most programmers, nor or any programmers that are looking at ceylon instead of kotlin. The java generics and type system is a daily hassle for me, and a major reason as to why certain code can not become easier or more maintainable to read and write.

[kinegg]

Yes, Ceylon was a good fit for a handful of people. Now it's dead.

[msx80]

The best thing on Ceylon is not just generics, but the whole type system. Its parts are great (say type union and intersections, or generics, or top and bottom types, or sequences and class layout in general etc) but the sum of them is so much greater. I think it's a language that really ties together its stuff in an elegant and coincise way. Also i'm a big fan of (the way they used) syntactic sugar, like for tuples or optionals etc. I don't think any other language out there is as good.

It has some drawbacks, as momomo said the Javascript backend was probably used by nobody, it was buggy and came with a lot of unpleasant glue (like the "dynamic" blocks, which are actually my least favourite thing in ceylon) but then again it showcased that multiple backends were possible. I think this is an important feature for a language. For example, an llvm backend was in development in the last days of activity, it would have ment to be able to create native executable on a huge array of platforms. Nowadays it could have meant a wasm backend, and running in the browser the right way (not via js).

The module system is not exacly immediate but not a showstopper either. Ceylon was built with big projects and big teams in mind, not to setup a script or two, so the cost of setting up modules it pretty small in comparison. I agree that it can make interoperation a pain, i experienced it myself.

In the end i'm very sad to see it go, it really ticked all the boxes for me.

[ShalokShalom]

In case Kotlin is not for you, consider Dotty: It is the complete re-implementation of Scala, and is getting released as the official Scala 3.

[ericdriggs]

If it takes 3 years to answer the question if the project is dead __ ?

[kikyokushida]

If it takes 3 years to answer the question if the project is dead __ ?

Then it had been 3 years and no one answered the question.

I'm really curious about whether someone will really answer this (and I think no one really knows, apparently), or we just assume it is and deal with it.

[ShalokShalom]

Yes.

[cory-vade]

I was very interested in Ceylon, I would be willing to volunteer.

[ShalokShalom]

It got killed. The project used to be supported by IBM, and they wanted to get rid of it. So they gave it to Eclipse, well knowing that it will end up dead, since nobody was every assigned or thought to actually maintain it. This is a strategy, to avoid an out roar of the community.

[luolong]

A slight nitpicking — the project was originally funded by RedHat (that was later aquired by IBM), and the move to Eclipse was indeed when RH pulled funding from the project and core developers essentially left for other projects.

As much as it grieves me, Celyon project has not seen any development in quite a few years, so it might as well be considered effectively comatose.

[momomo]

Can always be forked and / or revived. Depending on the licensing of course. It could be a good start for any project. I think what killed Ceylon was 99% its overfocus on being portable to JS. What a f***** ridiculous requirement that must have introduced such complexity to the codebase that it became unmaintainable.

If someone pulled all that crap out and left only the JVM parts of it, then most likely reviving it would be a much easier task. It would be as simple as adding synthetic sugar and patching existing issues or bugs.

I could live on JDK 6 and 7 really, so I could most likely live with a non progressing Ceylon as well, as long as it was 100% stable and I don't know how stable it is.

I think Ceylon has enough power syntactically that you should be ok with whatever exists already.

[msx80]

Can always be forked and / or revived. Depending on the licensing of course. It could be a good start for any project. I think what killed Ceylon was 99% its overfocus on being portable to JS. What a f***** ridiculous requirement that must have introduced such complexity to the codebase that it became unmaintainable.

Totally agree with this. The price wasn't worth the pain. The javascript porting was never really practical or efficient or even stable. One of the problems is that it was not just a "different code generator backend", it reached into language level with all the "dynamic" stuff etc. It looked like a second language bolted on the first. I would have much preferred it to be just JVM (or native like rust if ever). There was an experimental LLVM porting too.

If someone pulled all that crap out and left only the JVM parts of it, then most likely reviving it would be a much easier task. It would be as simple as adding synthetic sugar and patching existing issues or bugs.

I could live on JDK 6 and 7 really, so I could most likely live with a non progressing Ceylon as well, as long as it was 100% stable and I don't know how stable it is.

I think Ceylon has enough power syntactically that you should be ok with whatever exists already.

Yes, Ceylon was in a pretty good shape as it was, perfectly usable with most features already implemented. Also, being such a wonderfully designed language, it's not like it would need major rethinking in future (like java is experiencing this days).

I would love to contribute but the topic is a bit too complex for me to take on as a hobby project. But if anyone is going for a fork let me know and i'll be glad to be back experimenting with it.

Main show stopper for me was the unmantained Eclipse plugin. As much as i love Ceylon i can't work without an IDE.

[ShalokShalom]

I would consider re implementing it as a Truffle language.

You implement the AST and get the whole stack: JIT compiler, debugger, interop with tons of languages and so on.

Ruby got implemented within like 2 months. https://www.graalvm.org/

[Voiteh]

I tried to fork it and make it working. It was to complex. To many dependencies to make a release. I stareted few years ago hobby project which would extract only the essence out of Ceylon, and leave rest to attachable plugins. I had some success (generating java files out of unit test with java spoon). I switched to scala 3 as it has union and intersection types and AFIK similar type system with Nothing and Anything base types. It also has JS backend. Soo If any one would be interested in contribution please let me know :)

[ShalokShalom]

Yeah, Scala and Kotlin are far too good, to compete and fix the current codebase.

[momomo]

I would not consider Kotlin to be close to Ceylon. Lacking retified generics, as well as lacking multiple inheritance. Scala is a mess of its own.

Why are people trying to create a fork? To fix what? What are the pressing issues with Ceylon today? Is it IDE support? Then no fork should be needed. Albeit I would like it ripped into a minimal / essential version before anyone tries to improve on it.

[ShalokShalom]

Scala 3 is a complete rewrite and it supports multiple inheritance via traits. I consider it way more advanced than Ceylon will be. /unsubscribe

[momomo]

Yes, I am reading up on it. Looks impressive. I hope operator overloading is no longer a big thing in Scala. It surely made code hard to read and maintain.

[ShalokShalom]

Scala 2 used to be a horrible language. The funny thing is, Martin itself said, despite having dependent types and tons of more freaky stuff, the thing he found most productivity-enhancing, was indentation for block building.

If it wouldn't be for missing type inference and the overall (perceived) noise compared to F#, I would be very interested.

So also Graal, as said. 😃

[luolong]

Just playing around in my mind with some ideas for the future of Ceylon, should it ever get re-booted, but my 5 cents is that JavaScript back-end was not really what broke Ceylon.

Dynamic blocks were great programmer ergonomics features. Quite separately from JavaScript back-end.

There was also a Dart back-end, and an early prototype of LLVM back-end. I have no idea what state that ended up in.

The main issue with wider Ceylon adoption (and thus RedHat funding) was its strict built in modularity, that made adopting Ceylon into existing brown-field projects nearly deal-breaker.

You could really introduce Ceylon as a new green-field project, but we all know how many of those there. Majority of the development goes into the existing products and it was quite difficult to introduce Ceylon into such environments.

The amount of mental and programmatic contortion that needed to be performed to support that aspect of the language was huge compared to all the work on advanced language features and type system magic and various language back-ends.

And all it achieved was to simply raise the bar for developing Ceylon projects. Do not get me wrong, I personally loved the modularity and I believe that thinking about your dependencies early in the development process, makes for cleaner and better software architectures, but for the vast majority of developers out there, it is just another roadblock to hack through to get something done by the end of the day.

The fact that Kotlin focused so hard to achieve seamless interop with Java to the point of freely intermixing Kotlin and Java in the same source folder, gave them huge advantage in terms of adoption. As an anecdotal evidence I had a discussion with a coworker who used Kotlin in their project say, that as a language, they liked Ceylon much better, but they opted for Kotlin because it integrated much better into their development tools and flows.

The future, if there ever is one for Ceylon should probably have few alterations from the current code base:

1. Divorcing Ceylon compiler tool-chain from any specific javac version. As it stands, considering new JVM version release cadence, that will be just too much work as adjustments need to be made every 6 months. Not really something a small volunteer based commu8nity can keep up with .
2. Ditching or relaxing modularity constraints -- While I like modularity in general, it must be possible to add Ceylon to an existing Java project without requiring setting up the entire explicit module system. It does not mean that we should rip out the modularity entirely, but that should be offered as an optional wrapper layer around plain old Ceylon source files.
3. Ditch "oldschool" javascript backend. Instead of generating a reams of .js files, make an effort to build wasm binaries. Assuming there is aomeone willing to take the lead on that project.
4. Maintain Graal + Truffle compiler backend. That might be better and more future proof way forward towards achieving language interop (at least within JVM ecosystem) and since GraalVM can be used to generate native code, that might be a way forward towards bulding native binaries.

All that of course is heavily dependent on getting a team of developers working again on Ceylon language. Which, while not impossible, is rather unlikely at this point.

[ShalokShalom]

Implementing a new Graal + Truffle backend, is easier than maintaining the current code base and give you JIT, debugger, native binaries, interop with like 12 different languages (Python, Ruby, Nim, Rust, Crystal, Swift, C/C++, Haxe, Zig, Java/Typescript, every other LLVM language like Pony, F#/C# [in development] and R) besides the usual JVM candidates.

It`s just implementing an AST.

Tutorial

[momomo]

But can you really provide all of the Ceylon features like that? I am pretty sure there are limitations.

[ShalokShalom]

Does Ceylon provide more features than any of the languages mentioned above?

Java is also implemented this way. Just read on about it and judge for yourself 👍🏼

To be fair: The LLVM languages above are implemented via LLVM, not on their own. F#/C# have a CIL implementation. The others are implemented via AST.

[OndraZizka]

I have googled "ceylon lang dead" out of curiosity. I wanted to check Ceylon, so I typed "ceylon lang", but the completion suggested "ceylon lang dead" :D

I remember Ceylon as an internal announcement and a prototype in JBoss. IIRC, it was even being considered as the language for (parts of) JBoss Application Server 7, nowadays known as WildFly. But then, the work on WildFly made everyone so busy that Ceylon was an additional risk to an already risky project (a complete overwrite of the server core).

Compared to Kotlin, what advantages does Ceylon have? Union types is not really enough :) The only thing I miss in Kotlin (for a business development) is better work with all the DTOs between databases, logic and rest APIs. Otherwise it has so many goodies that I didn't even try them all.

[ShalokShalom]

Intersection types and how they interact with union types got named.

[momomo]

"Traits"

[ShalokShalom]

The website is down now as well. A WebArchive backup is available: https://web.archive.org/web/20221128104050/https://ceylon-lang.org

[ShalokShalom]

"Traits"

Are Traits exactly like that? You mean in Rust? Do you have experience with Ceylon?