> I agree it's a difference, but you really think that makes it worlds apart?
Yes. Well, it's one of the symptoms. Let me explain, but instead of using my own words, let me quote Ceylon's website:
Ceylon is a new programming language that's deeply influenced by Java, designed by people who are unapologetic fans of Java... But much of our frustration is not even with the Java language itself. The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project... Java interoperability is a major priority for the project. However, since Ceylon will be based on its own modular SDK, making a clean break from the legacy Java SDK, Ceylon will require new frameworks designed especially for Ceylon.
In one of the comments, Gavin King, Ceylon's chief designer, explains what differentiates Ceylon from other attempts:
What's going to be very challenging is the _platform_: the libraries and frameworks. This is where most of the potential value of this project resides, but it's where we have relatively more work to do than other projects which simply aim to leverage the Java SDK "as is".
So (my words now), Ceylon is a new language with a new ecosystem. It is a greenfield project that also can interoperate with "legacy" Java libraries. Kotlin is fundamentally different, as Gavin Kind correctly notes. It's decided from the get go that the Java ecosystem is the Kotlin ecosystem. That any Java library is an idiomatic Kotlin library and will be treated the same way as if it were written in Kotlin (that goal has not been achieved 100%, but certainly 95%). That meant that any language feature that would have made the Java ecosystem different from the Kotlin ecosystem was intentionally left out. For Ceylon, the goal was different. A new better language and a new better SDK. When interoperability was concerned, wrapper types were introduced and sometimes language features (that are not recommended for Ceylon code) like use-site variance, too. That is a completely different perspective with major implications. Kotlin really does have many thousands of Koltin libraries; Ceylon doesn't. OTOH, Ceylon is a more comprehensively designed language with less compromises.
I can speak from experience. I'm the author of several Java libraries. Some of them have hundreds of API classes and thousands of methods. Making those libraries "Kotlin idiomatic" was zero effort, and adding all the necessary "Kotlin bling" (e.g. cool use of inline functions which are Kotlin's poor-man's macros) took a couple hundred lines of code, none of which were really necessary. Clojure, BTW, is similar, but less ambitious in that regard. As all Clojure collections are Java collections and vice-versa, Rich Hickey specifically said that Java libraries should not be wrapped, as many can be used as-is, simply passing in and getting out plain Clojure types. Ceylon is different. If I have a library working with Java collections (which is pretty much all of them), any use by Ceylon code would feel foreign and may require wrapping or other special handling. But that is by design. It says so right there on the Ceylon website. How can any of that be FUD?
> There. Right there ;)
I see. Then consider changing the Ceylon website because it's just full of FUD about replacing the ecosystem. I might be guilty of spreading it, but I'm not the source.
Dude, I am quoting verbatim from your website. I have never said that you can't use Java libraries in Ceylon. I have said it is Ceylon's goal to replace Java's libraries, and that is lifted from your website. In fact, I don't even know why you're arguing, as you have not mentioned even a single point where you disagree with what I've said, yet you keep calling me a liar and a fabulist for some reason (for the record, I'm not). For all I know, we're in perfect agreement. What is it that I'm supposedly lying about? Have I misquoted Ceylon's stated design goals? Have I said that Ceylon's Java interop is bad? Ceylon's Java interop is radically different from Kotlin's because it was designed that way! You have clearly said that unlike other projects that want to work with the JDK as-is (Kotlin is one), Ceylon seeks to replace the libraries. You view that decision as a strength and place it high on the Ceylon FAQ, while Kotlin views the opposite decision as a strength. Both are fine, but the difference should be noted. It is you who is putting words in my mouth and insisting on arguing even though I don't even know what about. So unless you're willing to actually state what it is that you disagree with, please stop calling me a liar, thanks.
P.S. Ceylon's approach to Java interop resembles Scala's, which is yet another reason (aside from the adoption higher-order type-based abstractions) why I think Ceylon would attract Scala programmers, who are already fine with the approach.
Yes. Well, it's one of the symptoms. Let me explain, but instead of using my own words, let me quote Ceylon's website:
Ceylon is a new programming language that's deeply influenced by Java, designed by people who are unapologetic fans of Java... But much of our frustration is not even with the Java language itself. The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project... Java interoperability is a major priority for the project. However, since Ceylon will be based on its own modular SDK, making a clean break from the legacy Java SDK, Ceylon will require new frameworks designed especially for Ceylon.
In one of the comments, Gavin King, Ceylon's chief designer, explains what differentiates Ceylon from other attempts:
What's going to be very challenging is the _platform_: the libraries and frameworks. This is where most of the potential value of this project resides, but it's where we have relatively more work to do than other projects which simply aim to leverage the Java SDK "as is".
So (my words now), Ceylon is a new language with a new ecosystem. It is a greenfield project that also can interoperate with "legacy" Java libraries. Kotlin is fundamentally different, as Gavin Kind correctly notes. It's decided from the get go that the Java ecosystem is the Kotlin ecosystem. That any Java library is an idiomatic Kotlin library and will be treated the same way as if it were written in Kotlin (that goal has not been achieved 100%, but certainly 95%). That meant that any language feature that would have made the Java ecosystem different from the Kotlin ecosystem was intentionally left out. For Ceylon, the goal was different. A new better language and a new better SDK. When interoperability was concerned, wrapper types were introduced and sometimes language features (that are not recommended for Ceylon code) like use-site variance, too. That is a completely different perspective with major implications. Kotlin really does have many thousands of Koltin libraries; Ceylon doesn't. OTOH, Ceylon is a more comprehensively designed language with less compromises.
I can speak from experience. I'm the author of several Java libraries. Some of them have hundreds of API classes and thousands of methods. Making those libraries "Kotlin idiomatic" was zero effort, and adding all the necessary "Kotlin bling" (e.g. cool use of inline functions which are Kotlin's poor-man's macros) took a couple hundred lines of code, none of which were really necessary. Clojure, BTW, is similar, but less ambitious in that regard. As all Clojure collections are Java collections and vice-versa, Rich Hickey specifically said that Java libraries should not be wrapped, as many can be used as-is, simply passing in and getting out plain Clojure types. Ceylon is different. If I have a library working with Java collections (which is pretty much all of them), any use by Ceylon code would feel foreign and may require wrapping or other special handling. But that is by design. It says so right there on the Ceylon website. How can any of that be FUD?
> There. Right there ;)
I see. Then consider changing the Ceylon website because it's just full of FUD about replacing the ecosystem. I might be guilty of spreading it, but I'm not the source.