Live data from Hacker News

Why you might want to choose Ceylon

ceylon-lang.org

41–50 of 148 posts

Re: Why you might want to choose Ceylon

#41
I hope they'll redo some of the documentation with this upcoming release. Every time I read it, I am amazed by how comprehensive it is but still manages to miss some very important points.

Like the fact that on the main page, the link to the online editor is not under the "Try it out" section. The explore action from that section is also misleading.

Or a clean hello world, with a real project structure documented

Or the way collections are documented. Basically, you have section 6 from the tour of ceylon: Streams, sequences and tuples. But it's not obvious what is the big difference between streams and sequences and the fact that sequences borrow the array notation while being immutable doesn't help either. Even when you go to the List api, which is the interface any Java developer will look for,you can't find the mutable collections, because they live in another module.

Re: Why you might want to choose Ceylon

#42

It doesn't have extension functions. Since moving to Kotlin for my projects, I really enjoy the power that these provide: https://kotlinlang.org/docs/reference/extensions.html What does Ceylon give me over Kotlin?

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 native…

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.

Re: Why you might want to choose Ceylon

#43
post #30
post #10

Earlier quoted context omitted.

> I want to like Ceylon because it's the language Scala should be > but I just can't see people choosing the more polished language over the one with ten years worth of library and tool support when there's no USP beyond that polish It seems all a matter of time. What would Ceylon look like to you after some years of library and tool support?

The thing is Scala will always be 10 years ahead. I see Ceylon's future as looking like e.g. D - a better language than the alternatives in its niche, but without a USP to justify migration.

That's a big assumption to make. And probably one someone made about COBOL once...

Re: Why you might want to choose Ceylon

#44

Earlier quoted context omitted.

Yes, and that is really important when it comes to language use. The more people who use the language, the more it can develop and the more libraries that can be built for it. The other advantage of Kotlin is that it builds on top of the existing Java code base. Java has had decades to build up an ecosystem of frameworks and libraries. Kotlin builds on these with excellent interop.

I like Kotlin too but in fairness this is a Ceylon thread ;) From what I can see, Ceylon has a blend of strengths that should make it appeal to a certain segment of the market. On one hand, it's a fresh start and has a lot of the cleanness and terseness that I like from Kotlin. On the other, Gavin is clearly very much into type systems and type theory, and Ceylon has a more complex/powerful type system than Kotlin do…

Well the thing is that Ceylon offers fantastically smooth interop with both Java and JavaScript. That's one of it's main selling features for most people.

Re: Why you might want to choose Ceylon

#45
post #38

Earlier quoted context omitted.

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

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 th…

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

Re: Why you might want to choose Ceylon

#46

Earlier quoted context omitted.

Yes, and that is really important when it comes to language use. The more people who use the language, the more it can develop and the more libraries that can be built for it. The other advantage of Kotlin is that it builds on top of the existing Java code base. Java has had decades to build up an ecosystem of frameworks and libraries. Kotlin builds on these with excellent interop.

I like Kotlin too but in fairness this is a Ceylon thread ;) From what I can see, Ceylon has a blend of strengths that should make it appeal to a certain segment of the market. On one hand, it's a fresh start and has a lot of the cleanness and terseness that I like from Kotlin. On the other, Gavin is clearly very much into type systems and type theory, and Ceylon has a more complex/powerful type system than Kotlin do…

[deleted]

Re: Why you might want to choose Ceylon

#47
post #38

Earlier quoted context omitted.

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

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 th…

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.

Re: Why you might want to choose Ceylon

#48
post #2

Have they tightened up the floating point semantics? Or do you still get different rounding behaviour on the JVM, dart and JS? I want to like Ceylon because it's the language Scala should be (assuming that higher-kinded types made it in - I could never work without them). It's Scala with all the ugly parts polished away, Scala with ten years' progress in language design. But it does nothing that Scala can't. Scala mi…

A language without higher-kinded types or type-classes cannot be the language that " Scala should be ". And these aren't things that can be easily added later. And I don't think it will ever happen. And don't get me wrong, but software is about trust and I do not trust somebody like Gavin King for delivering a good language after Hibernate :) > Shapeless implicit macros to use tuples generically What can you do in Ce…

> A language without higher-kinded types or type-classes cannot be the language that "Scala should be"

You don't really get to say what other people think Scala should be. You like higher kinds, so do I, I'm glad they are in Scala but most people have never even heard the term and to them, they would much rather have a language with fewer features than one with more.

That's the goal that Ceylon and Kotlin are trying to achieve.

Re: Why you might want to choose Ceylon

#49
post #43
post #30

Earlier quoted context omitted.

The thing is Scala will always be 10 years ahead. I see Ceylon's future as looking like e.g. D - a better language than the alternatives in its niche, but without a USP to justify migration.

That's a big assumption to make. And probably one someone made about COBOL once...

I don't think the assertion is that Scala won't be superceded.

I think the assertion is that it is not obvious why it would be superceded by Ceylon. So, if there's no obvious reason to move to Ceylon, who is going to get the ecosystem to a level that it will compete with Scala's?

Now, I personally wouldn't be so bold as to suggest that it will always be 10 years behind Scala. I have no idea. But it isn't clear why the language itself is offering sufficient advantage.

More likely, at least to me, is that some of the ideas that Ceylon's shown are practical e.g. union and intersection types, will find their way into more languages because of it.

Of course, someone could produce the next big thing in it tomorrow and do for Ceylon what Rails did for Ruby. Then I'd go find a hat to eat.

Re: Why you might want to choose Ceylon

#50
post #14

I guess for me I don't need nor want JVM + JavaScript VM interoperability. My gut says this limits what can be done. I would rather have just one or the other. Maybe others feel differently.

This language looks pretty cool, but I do agree with your gut. The FAQ says:

"Note that not all Ceylon modules are available for both platforms. A module might be cross-platform, it might by JVM-only, or it might be JavaScript-only. Of course, ceylon.language is completely cross-platform."

Having some modules for JVM and some are for JavaScript-only would make things a little bit more confusing than if the language picked one. I haven't decided if this is a very significant thing or not.

Post reply on HN