Live data from Hacker News

Why you might want to choose Ceylon

ceylon-lang.org

21–30 of 148 posts

Re: Why you might want to choose Ceylon

#21
post #4
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…

Fully agree. I dabble with whatever new languages come out as any other language geek, but at work it only matters the languages validated by the IT department or requested by the customer. So, like many, I only work with languages blessed as first class languages in vendor SDKs. With Scala and Clojure barely being adopted by most Java shops (in perpetual terms), I don't see where Ceylon might fit in without a story…

Have you checked out Hello at www.amsdec.com?

Re: Why you might want to choose Ceylon

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

Making technology decisions with your gut is tricky. What if you happen to be hungry? The signalling will be all confused.

Re: Why you might want to choose Ceylon

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

Well, y'know, you could go with your gut - or you could actually try it out for yourself!

I think you'll decide your gut was wrong, but there's only one way to be sure.

Re: Why you might want to choose Ceylon

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

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

Re: Why you might want to choose Ceylon

#25
post #9
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…

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…

I think Go is a disastrous misstep (at least in the system-software contexts where I have to deal with it--obviously, you can do whatever for app languages), but I feel like your points as far as Java/Kotlin go are really well-put. I am honestly surprised at how happy I've been using Kotlin as the baseline server language for my current project (the backend of a fairly intricately orchestrated SaaS). I was not prepared to like it as much as I have; it's still very, very Java, but it blunts the worst parts of it from a syntactic and, where it can, a semantic perspective. Like--List is readonly, but retroactively applied to java.util.ArrayList, similar to IReadOnlyList in .NET. It's pretty nice. I am a Scala person, or I'd like to be but I find I write unmaintainable junk in it; Kotlin provides many of (though not all; I desperately want real traits, interfaces are not sufficient) the features from Scala that I need, without many of the negatives of Scala.

The biggest downsides I've encountered are around the deeper-magic Java interop, with stuff like Dropwizard's HK2 dependency injection system getting a little messy--especially around non-nullable parameters--but that stuff is, all things considered, a small part of the application.

Re: Why you might want to choose Ceylon

#26
post #4
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…

Fully agree. I dabble with whatever new languages come out as any other language geek, but at work it only matters the languages validated by the IT department or requested by the customer. So, like many, I only work with languages blessed as first class languages in vendor SDKs. With Scala and Clojure barely being adopted by most Java shops (in perpetual terms), I don't see where Ceylon might fit in without a story…

Aarrg auto-correction. perpetual => percentual

Re: Why you might want to choose Ceylon

#27
post #4

Earlier quoted context omitted.

Fully agree. I dabble with whatever new languages come out as any other language geek, but at work it only matters the languages validated by the IT department or requested by the customer. So, like many, I only work with languages blessed as first class languages in vendor SDKs. With Scala and Clojure barely being adopted by most Java shops (in perpetual terms), I don't see where Ceylon might fit in without a story…

Have you checked out Hello at www.amsdec.com?

No, I wasn't aware of it.

Re: Why you might want to choose Ceylon

#28

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…

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

Re: Why you might want to choose Ceylon

#29

Earlier quoted context omitted.

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.

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

Re: Why you might want to choose Ceylon

#30
post #10
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…

> 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.
Post reply on HN