
Why you might want to choose Ceylon - mikesname
http://ceylon-lang.org/blog/2015/10/27/why/
======
lmm
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 might need a pile of bodges to
offer these things - Shapeless implicit macros to use tuples generically,
type-level libraries abusing the implicit resolution rules to implement
unions, a retrofitted JavaScript backend. But that stuff has been written now,
and as a developer it works - maybe with a couple of ugly extra lines here and
there, but that's all.

I'm glad it exists, 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.

~~~
bad_user
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 Ceylon about this? Or are we talking about a dream?

> _a retrofitted JavaScript backend_

Not sure what you mean. Scala.js is reusing the Scala compiler in what happens
to be the cleanest transition I've seen to such a different platform. And
compared to other Javascript compilers, like ones for Ocaml or Haskell, this
one actually works well and stays up to date. Care to explain?

~~~
lmm
> 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. In other words I don't think it will ever happen.

I mentioned higher-kinded types; last I knew they were an experimental
feature. I thought Ceylon offered some way to do "open interfaces" (the vital
part of typeclasses IMO)? If not then that's definitely an issue.

> And what can you do in Ceylon about this? Or our we talking about a dream?

In Ceylon you have arity abstraction over tuples built in, so you can do
HList-style operations by default. Scala will supposedly add this in Don
Giovanni but in the meantime you have to use Shapeless with its implicit
macros and it's slightly less nice (e.g. the error messages are less clear).

>Scala.js is reusing the Scala compiler in what happens to be the cleanest
transition I've seen. Care to explain?

I think it's fair to call Scala.js "retrofitted", and I think the article is
right that a language that was designed from the ground up to be JVM-
independent will inevitably be better at it.

My whole point was that these are minor rough edges to Scala that aren't
really that important, so I'm not sure why you're being so defensive.

~~~
bad_user
Sorry, I sound defensive only because I'm in a bad mood, nothing to do with
the subject at hand.

Thanks for the clarifications.

------
sz4kerto
> its powerful Eclipse-based IDE

:( This is something that would, in itself, direct me to Kotlin or something
else. I know that Eclipse is a better fit for Ceylon (because both are
intimately related to OSGi), but I really wouldn't want to go back.

~~~
netcraft
I agree, but there does seem to be some development towards an intellij plugin
for it: [https://github.com/ceylon/ceylon-ide-
intellij](https://github.com/ceylon/ceylon-ide-intellij)

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

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

~~~
gavinking
Well where there is a big difference between the underlying capabilities of
the platform, differences are unavoidable.

I mean, examples of things that are cross-platform in Ceylon: collections,
localization, promises, regexes, HTML construction, logging, testing,
dates/times.

Examples of things that are platform specific: I/O, database access,
filesystem access, distributed transactions, the HTTP server.

That's pretty reasonable and natural, isn't it?

~~~
lomnakkus
The date/time cross-platformness is a big deal for business-type applications,
at the very least. You tend to transfer/use a lot of dates/timestamps/what-
have-you in that type of application. (This is a constant source of pain for
me in scala.js.)

~~~
gavinking
ceylon.locale is also shaping up to be really useful. Localization in JS is
just terrible.

~~~
lomnakkus
Yes, that's another of my pet peeves with scala.js since it basically splits
your world into two around formatting of dates/time/currency/etc. (Things may
have changed recently, but it was sorely lacking up until a few months ago.)

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

~~~
gavinking
Would you please open an issue here with the things you would like changed:

[https://github.com/ceylon/ceylon-
lang.org/issues](https://github.com/ceylon/ceylon-lang.org/issues)

Thanks.

------
danesparza
This is great, but who is using it? I enjoy learning new languages, but
knowing who is using it (and perhaps why) is a good indicator of momentum in
my opinion.

------
aembleton
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](https://kotlinlang.org/docs/reference/extensions.html)

What does Ceylon give me over Kotlin?

~~~
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/](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](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/](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?

~~~
pron
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 try. I will also reiterate that I can
certainly see that other people may prefer Ceylon's design goals over
Kotlin's.

~~~
gavinking
Now you're just lying. You said:

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

And the context of the comment was _quite clearly_ Ceylon interoperating with
Java as anyone can verify.

I have a friendly request for you: please don't comment about Ceylon on any
more hackernews or reddit threads. It's great that you like Kotlin and are
having success with it. I'm happy for you. Post about how great Kotlin is on
all the Kotlin threads you like.

But it's just not a good thing for anyone that you're going posting on Ceylon
threads, speculating about made-up problems with Ceylon, and pretending you
know Ceylon when you don't.

So please stick to the Kotlin threads is all I'm asking, OK?

~~~
twic
> I have a friendly request for you: please don't comment about Ceylon on any
> more hackernews or reddit threads.

This is really unproductive. Reddit and HN are discussion forums; what we want
on them is more discussion, not less. We want high-quality, accurate,
discussion, but if we're not getting that, the solution is to raise the
quality, not reduce the volume.

In particular, the last thing i, as a reader of discussions, want is for a
discussion forum to turn into a confederation of theocracies where nobody but
the local priesthood are allowed to speak.

So, pron, i also have a friendly request for you: please continue to comment
about Ceylon wherever you like - but make sure you've done your homework
before doing so!

Specifically, if you could produce a concrete example of how Ceylon's reified
generics interact poorly with Java's generics, that would be really
interesting. If you could produce an example of how non-Ceylon reified
generics interact poorly with Java generics, then that would be interesting,
and gavinking could explain how Ceylon avoids the problem, which would also be
interesting. And if you find that actually, there isn't such a problem with
reified generics, that would be interesting too, not least for you.

~~~
justthistime_
He did the same uninformed rants about other languages for a long time
already. It's unlikely that he will do his homework any time soon.

~~~
pron
What's unlikely is that you'll ever try to understand what it is that I'm
saying when I talk about language design goals.

------
lfnon-heretic
> Furthermore, implementation of a compiler backend for the Dart VM is already
> quite advanced ...

Curious if this work is still fruitful, now that Google has abandoned its
plans to integrate Dart VM into chrome.
[http://techcrunch.com/2015/03/25/google-will-not-
integrate-i...](http://techcrunch.com/2015/03/25/google-will-not-integrate-
its-dart-programming-language-into-chrome/)

------
lighthawk
I looked for example projects in Ceylon with step-by-step info on how to
setup/deploy:

* Hello World web application

* Simple online store implementation (authN, database access via ORM layer, logging)

* Todo MVC implementation

* RESTful/XML/SOAP web services

* RESTful/XML/SOAP clients

* Examples for writing AngularJS and React front-ends with Ceylon back-end services, with info on how to host such as to minimize and cache assets and server-side query caching and either side-loading or multi-table joined/extended data structures, updating and reading/accessing those data structures partially.

* Examples for easily timestamping and userstamping models

* Examples for using testing frameworks: unit, integration, (web) acceptance

Here's what I found in looking for that:

* This hello world: [http://ceylon-lang.org/documentation/tour/basics/](http://ceylon-lang.org/documentation/tour/basics/)

* No Ceylon JS example at [http://todomvc.com/](http://todomvc.com/) but this Todo list: [https://github.com/vietj/cayla-mvvm/blob/master/source/io/ca...](https://github.com/vietj/cayla-mvvm/blob/master/source/io/cayla/todomvc/TodoList.ceylon)

* Two examples in what I assume is the official examples git repo at: [https://github.com/ceylon/ceylon-examples](https://github.com/ceylon/ceylon-examples) containing N-queens and Game of Life only.

Also, I'd want to see benchmarks. Show me how much it is "like" performance of
equivalent Java, Dart, and JS as is claimed by comparing to maybe a Play
Framework app, the Dart example client-server
[https://www.dartlang.org/server/google-cloud-platform/app-
en...](https://www.dartlang.org/server/google-cloud-platform/app-
engine/client-server/) , and a simple MEAN stack and/or full-stack example
using ReactJS.

In addition to those examples, I'd want to see a larger community behind it
with a variety of projects, e.g. specialized ORM, larger web app/services
framework, simple web app/service framework each that have their own
communities using it.

I think it is cool, but I don't think it is even in the same ballpark with
solutions/combinations like Play+Scala, MEAN, Rails, Elixir+Phoenix, etc. for
wide application in web/services.

~~~
taiar
Here are some other articles with examples I recently wrote on Ceylon:

\- [http://taiar.github.io/log/2015/10/09/ceylon-programming-
lan...](http://taiar.github.io/log/2015/10/09/ceylon-programming-
language.html)

\- [http://taiar.github.io/log/2015/10/23/ceylon-programming-
lan...](http://taiar.github.io/log/2015/10/23/ceylon-programming-language-
usage.html)

Basic toy stuff but has some points on Java interoperability and explores
other language aspects.

------
NanoWar
I don't like the extensive use of the ` character, because it's really hard to
use on a german keyboard: it get's added twice :( Other than that this looks
great!

~~~
ake1
you might want to look into changing to another keyboard layout. as a swede,
using altgr+[7-0] to get (curly)brackets is just ridiculously cumbersome
compared to say a us layout.

------
vorg
Scala and Kotlin are mentioned so many times in these comments about Ceylon
(42 times and 66, respectively, as I write), but no mentions of dynamic
languages Groovy, Jython, or JRuby. I guess that shows there still a clear
distinction between languages built from the ground up for building systems,
and languages originally built for scripting, build scripts, and testing.

~~~
lmm
I don't think the distinction is the one you're making it. The original
intentions of languages are accidents of history (Java was originally for set-
top boxes), and the likes of Python and Ruby are perfectly legitimate
languages. The best options on the JVM happen to be typed, but there are good
untyped languages and bad typed languages, and parochial typed languages and
general-purpose untyped languages too.

------
hcarvalhoalves
Looks like a smaller Scala that also compiles to JS. Might be worth a shot.

------
lobo42
Did anybody checkout xtend-lang.org? It's for sure better in terms of Java-
interoperability and IDE plugins (Eclipse _and_ IntelliJ) And it even has
macros!!

------
trhway
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!

~~~
Lazare
Speaking as someone who has done quite a lot of work using languages with
terse lambda syntax...

...that's just not ever an issue.

~~~
sixbrx
i think the poster thinks that with the fat arrow definition, name becomes an
implicitly called function wherever it is used. I wouldn't like that either.

but, I dont know if thats really the case though (I dont know ceylon). I think
that fat arrow line would just become a no op instead, creating a lambda and
throwing it away immediately ("name" being the param name in the lambda and
nothing more).

~~~
gavinking
It's just a getter. Lots of languages have getters.

~~~
sixbrx
Ah that makes sense, thanks. I missed the implicit "we're in a class
definition" in the original post.

------
oldmanjay
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!

