[UnFroMage]

> The level of interoperability, though, is radically different from Kotlin's

There's no truth in that. Sure, it's possible that there are some differences in how we both do interop, and that some things are easier in one or the other, but overall you've no basis for claiming that, and I strongly suspect you haven't tried Ceylon for interop at all or you would not say that.

When you do try and find interop things that we should improve, please let us know in our issue tracker and we'll do our best to fix it.

Meanwhile, please stop with the FUD.

[pron]

> Sure, it's possible that there are some differences in how we both do interop

There are no "some differences", but a radically different philosophy which is at the very core of the language's design. A Kotlin list is a Java list and vice-versa; a Kotlin map is a Java map and vice-versa; a Kotlin set is a Java set and vice-versa. The same, BTW, is true for Clojure, but unlike Clojure, Kotlin doesn't just keep the interfaces, but also the implementations. Kotlin hardly even has a standard library. The Java standard libraries are Kotlin's standard libraries (modulo some extension methods). Ceylon has its own standard libraries, and, in general, Java libraries are not idiomatic Ceylon libraries. That Ceylon even has CeylonList/JavaList types shows how the two approaches are worlds apart. Comparing it to Kotlin in that regard is ridiculous, and I don't even know why you'd try. It is one of Ceylon's strengths that it has its own library, and one of Kotlin's that it doesn't. Each appeals to different needs, and I don't see why you feel you should blur the differences.

> When you do try and find interop things that we should improve

It's not about that. You may think that Ceylon's Java interop is great. It may be just the right amount of interoperability that you want. But claiming it is anywhere near Kotlin's is just preposterous. I didn't say that Ceylon's Java interop is bad, but it's just not even in the same ballpark as Koltin's. But that's OK, because the two languages have different philosophies.

> Meanwhile, please stop with the FUD.

Please stop calling it FUD. I have never, ever said people shouldn't use Ceylon, that it's a bad language or even that Kotlin is better. I have emphasized the big difference in design goals between the two languages that makes them very different in practice: Ceylon has an advanced, very elegant, beautiful type system, while Kotlin has many thousands of libraries. Where is the FUD?

OTOH, instead of calling it FUD, and since this is a Ceylon thread, I would very much like to hear a justification for Ceylon's design; not the choices of the particular language features -- I will readily admit that Ceylon is the best language ever devised by man -- but why being better at the language/typesystem level, without offering a new paradigm warrants switching a language in the first place. After all, it doesn't offer anything radical when it comes to concurrency (like Clojure or Erlang or Go) or functional purity/equational reasoning (like Haskell). It's just cleaner and more elegant than Java or Scala. OCaml is another such beautiful, well-designed language, but, perhaps sadly, it has hardly seen any adoption. Why do you believe that is enough to get people to switch to a new language? For example, I know that Joe Armstrong thought a lot about the problem of fault-tolerant systems, and he came up with the idea of isolating failure; Rich Hickey thought a lot about state and identity and came up with Clojure's data structures and controlled mutation. Their reasoning is fascinating. What is that behind Ceylon's (I can tell you the reasoning behind Kotlin)? Did you reach the conclusion that a major obstacle to building modern software at this point in time is deficiencies in the type system? I'm not mocking, and I'm not saying it isn't, but unlike in Clojure's, Erlang's, Rust's and Kotlin's case (or Haskell or Scala), I've just never seen the Ceylon philosophy explained.

I've read Ceylon's guiding principles, but they haven't answered the question. If simply doing the same thing better justifies starting over, then supposing Ceylon takes off, in a few years Ceylon, too, will accumulate cruft, and its design mistakes (in the language or libraries) will become apparent. What will Ceylon advocate then? Backwards compatibility or breaking changes (or maybe a new language altogether)? And if the idea is to start over every 20 years -- I can see the merit in that argument -- why not a whole new paradigm? Is everything OK except mistakes in library design and the type system?

You don't have to answer, and you can either address or ignore my views -- but please don't call them FUD.

[UnFroMage]

> But claiming it is anywhere near Kotlin's is just preposterous.

The only example you give is that they don't have their own standard library. I agree it's a difference, but you really think that makes it worlds apart?

I mean, in Ceylon you can also use the JDK, so I don't quite see the big thing, but even then, OK that's one difference (and it's a justified one too, but fine, OK). That's really the thing that makes you say that we have Java interop a world apart? I understand it may be an important point for you, but I don't understand how you can extrapolate that it's so important for everyone.

> while Kotlin has many thousands of libraries. Where is the FUD?

There. Right there ;)

[pron]

> 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.

[gavinking]

>> Then consider changing the Ceylon website because it's just full of FUD about replacing the ecosystem

It is not. You're a fabulist. Your behavior on this thread is worse than obnoxious.

>> 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.

You can use them in Ceylon with no problems at all.

Please stop lying about Ceylon and please stop putting words in our mouths. Thanks.

[pron]

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.

[pron]

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.

[gavinking]

Earlier today I, in all sincerity, invited you to our Gitter channel, where there's always people discussing this stuff night and day. That invitation is still there. You're welcome any time you like.