[gavinking]

Well, if you read the linked article, a number of things are mentioned, including:

- union and intersection types

- an elegant and powerful representation of tuple and function types

- reified generics

- the cleanest solution to the problem of null

- awesome modularity

- a language module [that] completely abstracts the underlying runtime, and offers a set of elegant APIs that vastly improve on those available natively

- a language specification

None of which is offered by Kotlin.

That's quite a lot, actually.

[aembleton]

- union and intersection types -- I'll have to read up on this

- an elegant and powerful representation of tuple and function types -- Okay, Kotlin could do with this

- reified generics -- This is apparently expensive on the JVM: http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/

- the cleanest solution to the problem of null -- I think saying that `String? x = "abc"` is cleaner than `var b: String? = "abc"` is subjective. -- Does Ceylon have Safe Casts? https://kotlinlang.org/docs/reference/null-safety.html

- awesome modularity -- Something I'll need to look into

- a language module [that] completely abstracts the underlying runtime, and offers a set of elegant APIs that vastly improve on those available natively -- I guess the improvement in abstraction comes from the Reified Generics -- Have you got any examples of where the API is superior to that of the Kotlin one? For example, with Kotlin's extension functions Java File object has been extended with a readLines() function that returns all of the lines of a File as a List. I was impressed when I saw that. Underneath it is doing the usual BufferedReader and InputStream boiler plate work that you would normally write in Java.

- a language specification -- https://kotlinlang.org/docs/reference/

[gavinking]

For the record:

- Kotlin does not have tuples, and doesn't allow abstraction over function -arity. So no, it can't to that.

- Reified generics are simply not expensive, at least not the way Ceylon implements them. But sure, Ceylon's reified generics were implemented by Stef Epardaud who is the best programmer I've ever worked with, so I can understand if some other people find them difficult to implement efficiently.

- I'm not talking about syntax. Syntax is uninteresting. I'm talking about semantics. In Ceylon, optional types are a trivial syntax sugar for a union type, not a hacked-in special case in the type system, as they are in Kotlin, and that means that I can do more with them, for example they naturally combine with union and intersection types to do useful things.

- Your link to documentation for Kotlin does not include any specification for the language. Do you know what the word "specification" means in this context?

Finally, I strongly recommend that you take the time to read the Ceylon documentation and inform yourself about the language. You'll find lots of really interesting ideas and information in there, and I'm certain you'll love the language!

[pron]

The problem with reified generics isn't their efficiency, but that they don't play nice with other generic types on the platform (which is the vast majority).

Every choice in Kotlin's design has been intentional with one idea in mind -- compromise on purity in favor of interoperability (to lower the cost of adoption). So, of course you can do more at the language level with Ceylon, but Kotlin set out to do less in that arena by design. OTOH, Kotlin has several orders of magnitude more idiomatic (or very nearly idiomatic) libraries than Ceylon.

There's a very clear tradeoff here, and Kotlin and Ceylon have been designed with very different underlying philosophies. The only point you can argue about is which language gets you more bang for the buck. Kotlin has intentionally chosen less bang for less buck, while Ceylon has chosen the opposite. Personally I believe that almost all language-level abstractions are relatively low-bang[1] -- or certainly have diminishing returns -- and therefore language purity should always be compromised for almost any other extra-linguistic feature (if it's a language designed for the industry rather than academia), and so I think that Kotlin has made the better decision and gives you almost as much bang for far less buck. But only time will tell, and arguing about this at this point is just a matter of personal preference. I can certainly see some people preferring the one and some the other.

Another way to look at it is that Ceylon was designed to appeal to Scala people, while Kotlin was designed to appeal to Java people :)

[1]: By that I mean that they're always useful for something, but in the end have a low impact on total productivity (which includes more than just writing the code).

[gavinking]

By the way, pron, as more general complaint, your comments about Ceylon are always very uninformed, but you state them as fact.

How about you actually spend some time learning the language first before commenting any more about it here or on reddit. Because it really wastes my time and raises my stress level having to correct your - probably unintentional - FUD. It's clear that you don't know Ceylon, so please stop telling everyone else stuff that you're just guessing at.

OTOH, if you want to get answers to any questions you might have you are extremely welcome to come on our Gitter channel and ask them, and I promise we're always very patient about explaining stuff there. I make that offer in complete sincerity.

[pron]

I don't think they are uninformed, so feel free to correct me when I'm wrong. My "long-winded" comment wasn't about generic types -- just the first, small bit -- and that bit wasn't about Ceylon's generic types, but about generic reification on a shared platform like the JVM in general, which bakes a variance model into the class. As long as you're the only one doing reification you're sort-of fine, except all those erased generic types aren't quite first-class citizens. I should have clarified that.

As to the rest (and the lion-share) of my comment, I don't think it requires further clarification, and I don't see why you'd even think it's wrong. You've set out to create a new language with new, clean type semantics and a new runtime library, while Kotlin, in contrast, has had a different goal altogether. It doesn't even have its own concrete collection classes, so that's a radically different level of interoperability and a radically different design. That is the major difference between the languages rather than the list of features you've named in an answer to a question by someone else (and like I said, either approach has its proponents), so from my perspective it was you who was adding to the confusion, which I wanted to correct.

The answer to the question "what is the difference between Ceylon and Kotlin?" IMO (at least when the JVM target is concerned) is that Ceylon is a completely new "greenfield" language with a new, powerful type system, new semantics and a new runtime library, while Kotlin is "a better Java", a language preserving Java's semantics and standard library while solving its pressing shortcomings and providing a more modern syntax, and made to be adopted piecemeal into Java codebases. Of course there's some overlap, too, but that's the different in philosophies in broad strokes. In terms of features, some are similar (with Kotlin adopting some of Ceylon's ideas) and some are different, but that isn't the big difference.

For those reasons, BTW, while it would be very nice to have a Kotlin spec, it isn't as necessary, as most its semantics are borrowed from Java.

Of course, you may well think that those linguistic features are a bigger difference than the design goals, but I will disagree (due to the reasons I laid out in my other comment), and no amount of Ceylon expertise is relevant to that disagreement.

[gavinking]

Well it should be very clear, that if you believe that Ceylon has a problem interoperating with Java's unreified generics, that you don't know enough about Ceylon to be able to comment with any sort of certainty on the topic of Ceylon and Java interop.

Because you quite obviously have never even tried it once.

That's clear, isn't it?

[gavinking]

"The problem with reified generics isn't their efficiency, but that they don't play nice with other generic types on the platform (which is the vast majority)."

This is simply nonsense. You made it up. There have been zero complaints about problems Ceylon has in interoperating with Java's generic types, since they simply don't exist.

I can't believe you just wrote such a longwinded comment about a nonexistent problem that you imagined out of whole cloth.

[ngrilly]

Could you grossly explain how reified generics are implemented and how they interoperate with Java's generic types? It would be a good way to defuse pron's claim.

[gavinking]

"Another way to look at it is that Ceylon was designed to appeal to Scala people"

This is quite clearly not true, and yet another assertion that you just made up and stated as fact. We're Java not Scala developers, and we designed Ceylon for other people like us. Don't try to tell me what my own motivations were.

In fact, it's very difficult to imagine, even charitably, why you would possibly be motivated to make such a claim unless you were deliberately trying to spread misinformation.

[pron]

Yes, I did make that bit up. In fact, I misspoke, and I apologize -- that statement was wrong. What I really wanted to say is that Kotlin would appeal more to Java people while Ceylon would appeal more to Scala people, and even that is made up, but I still think it's true. How did I come to such an outrageous conclusion? By reading (with great interest and enjoyment!) blog posts by you about type functions in Ceylon. A fascinating topic (and Ceylon's handling of it is very elegant), but one which -- I believe -- appeals more to those who place much importance on such type-based high-order abstractions in their language, and less to those drawn to "blue-collar" languages.

[ssmoot]

As a former Ruby dev, and current Scala dev, I actually think Ceylon would appeal more to Rubyists.

Syntax-wise, Ceylon is not a very pretty language at first glance. LHS types and semi-colons. Not really a lot to like from a syntax perspective for your average Scala developer I think.

But that's just my opinion.

[udalov]

Could you please explain how the internal representation of null in the language's type system has any effect on the semantics of code written in that language?

[gavinking]

Sure. So I'll give you one very over-simplistic example. Let's assume that T is an unknown type (a type parameter).

You can form types like Object&T, and if T is an optional type of form S|Null, then that is reduced automatically to the type S by the typechecker. But if T is not an optional type, then it just remains T.

Very useful to be able to do this kind of trick in generic code.

And note that nothing here was using any special reasoning about Null: this is all just the totally generic reasoning for union types in general.

[lmm]

Null in Ceylon is just another type, and nullable-X is just another union type, so you can use them sensibly with generics. With Kotlin if you want to write a generic method like "add two values" and have it handle nullness polymorphically then you have to think about it.

[UnFroMage]

> - reified generics -- This is apparently expensive on the JVM: http://blog.jetbrains.com/kotlin/2014/12/m10-is-out/

FTR I am not sure I believe that explanation. I was with Gavin a few years ago when Andrey Breslav asked us if we were going to implement reified generics (we had not yet at the time) because they were having trouble implementing it and so if we were not going to implement it, they would not bother.

We haven't talked about this conversation publicly in the past because to be brutally honest most of it would make them look really bad, and it's likely that we won't, but this anecdote was very relevant to the discussion about reified generics.

My guess is they tried and failed, strictly based on this conversation. It's possible that they really considered it too expensive, but I since that's not backed by public experiments and our own experiments tell us it's not that expensive for the benefits it gives us, I don't _have_ to believe them ;)

[lukedegruchy]

-reified generics: From what I've seen, the Ceylon guys have done a good job of implementing this and they make flow-sensitive typing possible. Without out, the benefits of union types don't fully materialize. See http://ceylon-lang.org/blog/2015/04/19/observable/

- problem of null: Ceylon uses union types to union between the class in question (ex String) and Null, which is a type separate from Object. Therefore, the typesystem enforces this. And yes, Ceylon has the exists operator, which means you can do if (exists stringOrNull) to instanceof/cast at the same time.

- elegant APIs - With regard to file I/O: https://modules.ceylon-lang.org/modules/ceylon.io/1.1.0/doc

- language spec - Ceylon's is much more detailed: http://ceylon-lang.org/documentation/1.1/spec/html_single/

[gavinking]

This is what a specification looks like:

http://ceylon-lang.org/documentation/1.1/spec/html_single/

[randomThoughts9]

Not the best place to mention this, but I never understood why, at least when talking with the functional oriented people, the union types are not explained as providing first level support for the Option, Either and the Try monads.

[lomnakkus]

Well, I guess it depends on what you mean by "first level" support.

For example, the T|Null thing doesn't give you code composability of the type monad transformers do -- at least as far as I understand it[1]. (I'm sure there are other things, but that's the first thing that popped into my head.)

FTR, I am a typed-FP weenie, but I still find Ceylon quite interesting, though I haven't done anything non-trivial in it yet.

[1] I still haven't fully understood the (experimental) HKT support, so maybe that can accomodate this?

[randomThoughts9]

There are some places where monad composability would improve your code but in general, at least the way I see it, you can replace a scala for comprehension with a set of IF statements, each IF eliminating a wrong value (null, exception, etc). Not to mention that you can have as many options as you like (A|B|C|D|E), whereas the mentioned monads must be composed in order to capture the same thing.

But it's true I never built a big ceylon project, so I can't say I know how that works out in practice.

[gavinking]

Yes, it's one good way to think about how they fit into the whole ecosystem of the language. Thanks.

[dlandis]

> Well, if you read the linked article, a number of things are mentioned

The article was an overly verbose 2000 word wall of text.

[gavinking]

What has happened to our culture? People are actually proud of being too lazy to read anything longer that a tweet?

[vvanders]

I think it's a fair complaint, it is fairly dense and as something that's supposed to encourage adoption you might want to have a quick high-level summary.

On a slightly different note(and no idea if this goes against HN guidelines) but you've got a fairly argumentative tone. If you're really interested in seeing the language flourish I'd try not being as combative.

Community is just as important as how well a language is designed and based on the tone of a lot of the sub-threads here I'm not really inclined to look into Ceylon any further.

[bassislife]

Alas, to his defense, it's slightly unnerving to read malinformed, biased critics all-thread long.

I would really advise him to try and ignore most of them if he wants to keep his sanity though. (serious, been there, done that.) Especially since I think that the language looks quite promising.

Sometimes, it's ok to correct things even if a little harshly though. People will always find a dumb argument anyway.