Live data from Hacker News

Why you might want to choose Ceylon

ceylon-lang.org

71–80 of 148 posts

Re: Why you might want to choose Ceylon

#71
Part of me fears the GWT successors that could end up built out of this.

Part of me is intrigued by the excellent modularity story.

Part of me is excited to try out the type system.

Most of me wonders if I'll get time or an opportunity to explore.

Overall, this generation of languages is pretty exciting!

Re: Why you might want to choose Ceylon

#72

Earlier quoted context omitted.

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…

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

> - 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 ;)

Re: Why you might want to choose Ceylon

#74
post #57

Earlier quoted context omitted.

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?

I didn't say that Ceylon has a problem interoperating with Java's unreified generics, just that reified generics on a shared platform have their own issues. The level of interoperability, though, is radically different from Kotlin's. And yes, I have never tried Ceylon because its stated design goals -- while great -- are not what I'm looking for. If I got the design goals and philosophy wrong I'll happily give it a t…

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

Re: Why you might want to choose Ceylon

#75
post #43

Earlier quoted context omitted.

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

Don't forget that, running on the JVM with great interop means that any Ceylon program has instant access to a huge ecosystem, including not just Java libraries but also Scala libraries. I was able to use Apache Spark in Ceylon ;)

Re: Why you might want to choose Ceylon

#76

Earlier quoted context omitted.

>Having IntelliJ just work is always discounted more than I think people should. To be fair, Kotlin has the advantage of being created by the company that makes IntelliJ, so it's got a big head start IDE-wise.

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.

Ceylon also has excellent Java/JVM (and JavaScript) interop. You should try it :)

Re: Why you might want to choose Ceylon

#77
post #9

Earlier quoted context omitted.

I think it's part of a general trend of language designers (and even language fans) not understanding what makes languages work in practice. For academic languages this may not matter, but if you actually want your language to be used, you need to pay attention. A recent study[1] has shown that "extrinsic" factors (performance, tooling, familiarity, libraries) matter a lot more than intrinsic factors (syntax, abstrac…

Yeah, the Kotlin inter-op is really well done. Having IntelliJ just work is always discounted more than I think people should. I do wish Kotlin had more pattern matching semantics but that's just me being picky, it's a really nice language.

Ceylon has an IntelliJ plugin in the works that builds on the solid foundation of the Eclipse plugin, so it's picking up features really fast. It should be out in a few months.

Re: Why you might want to choose Ceylon

#79
post #33

Earlier quoted context omitted.

> Well, if you read the linked article, a number of things are mentioned The article was an overly verbose 2000 word wall of text.

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

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.

Re: Why you might want to choose Ceylon

#80
i want it! it will increase my job security with features like this :

==

String name => firstName + " " + lastName;

And an assignment:

String name = firstName + " " + lastName;

In the first example, the expression is recomputed every time name is evaluated. In the second example, the expression is computed once and the result assigned to name.

==

A function which looks like just a variable and recomputed each time! Happy debugging my code, suckers!

Post reply on HN