Stack OverflowWhat's the difference between Scala and Red Hat's Ceylon language?
[+49] [6] John Bryant
[2011-04-13 07:16:28]
[ java scala programming-languages jvm-languages ceylon ]

Red Hat's Ceylon [1] language has some interesting improvements over Java:

I don't know Scala but have heard it offers some similar advantages over Java.

How would Scala compare to Ceylon in this respect?

(1) Having taken just a brief glance over the slides it bears a strong similarity with Groovy, except that it uses static typing. The example code "feels" pretty groovy. - Joachim Sauer
(3) Scala is functional. That's probably the biggest difference to start with - charisis
Scala is not functional. Not even close. - Tony Morris
(18) Scala recognises functions as first-class citizens, and makes extensive use of immutability, closures and pattern matching. It absolutely matches one very valid definition of "being functional" - Kevin Wright
Scala does not make extensive use of immutability at all, but does so only in contrast to other contexts that are extensively anti-immutability. It absolutely does not match any valid definition of a functional language. Not even close. - Tony Morris
(3) Scala's collections are immutable per default, so are variables. I don't know your definition of "not making extensive use of immutability", but mine is different. - Axel Gneiting
(9) For a strict language, Scala is as functional as any other, if "being functional" means "makes it easy to write programs in a functional style". If, however, "being functional" means "makes it hard to wite programs in a non-functional style", then Scala is not functional. The only thing I really miss in Scala in some kind of effect tracking system. - Daniel C. Sobral
Static typing is not an "improvement over Java"... - PhiLho
@PhiLho - That would be an example of "keep the good", then, wouldn't it? - Rex Kerr
(1) I would say Scala "supports" functional programming instead of "is functional". As for immutability, there is nothing in Scala-the-language that encourages immutability intrinsically, you need to make a conscious effort to use immutable structures. And Scala's collections and variables are not immutable by default. - Cedric Beust
(2) When I create a list or map, with no explicit imports, it's immutable; If I want different then I have to put in a special request. How can this not be considered "by default"? When creating a value, I must explicitly state if it's a val or var; I wouldn't choose a var without good reason, how does this not "encourage" immutability? - Kevin Wright
(11) I would compare them as follows: Scala exists, Ceylon doesn't. Ceylon today is where Scala was circa 2002. - Seth Tisue
(1) Never thought it would be, but Cedric is (mostly) right! - Tony Morris
If you guys ever try to "make extensive use of immutability" with Scala, you'll find it falls to its knees, crippled, begging for mercy. Though, less so, than for other programming environments. Honestly, give it a crack. Don't believe the hype yo! - Tony Morris
(1) Nobody ever claimed that scala is purely functional, just that it was explicitly designed to support the paradigm, and does so with an ease that is (at the very least) on par with its support for an imperative style. It's a hybrid, and never claimed otherwise, though best practice is increasingly favouring more functional designs. - Kevin Wright
Nobody ever claimed that somebody claimed that scala is purely functional. I know what the scala brochure says about "supporting the functional paradigm", but I also know many claims that are wrong. Among many hoaxes and a particularly funny one, Scala is also not a "hybrid." I'm not sure why repeating bullshit at me, that we all know I have seen, is expected to persuade. Why not study the claims to determine for yourself? - Tony Morris
More details can now be found in the Introduction to Ceylon series. - hishadow
[+49] [2011-04-13 08:19:05] Rex Kerr

I assume you read the same Slashdot article [1] I did (with linked slides).

The short answer is that Scala already does everything that Ceylon is supposed to do except

  • Focus on ease of learning
  • Syntactic sugar for sequences
  • Syntactic sugar for strings

It also does things that Ceylon does not (yet):

  • Implicit conversions
  • Trivially easy closure declarations
  • Higher-kinded types
  • Operators are just methods; use methods or operators in infix notation
  • Syntactic sugar for pattern matching, collections, and XML
  • It exists
  • It has an extensive functionally-inspired collections library

These features allow Scala to implement as libraries (or modifications to libraries) things that usually require changes to the language (or a new library), and allow the programmer to express powerful concepts in a compact and still relatively clear way.

(Also, note that the features of Ceylon are rather similar to those of Gosu [2].)


@Joachim Sauer - Thanks for adding the links. - Rex Kerr
(8) Implicit dictionary passing and higher-kinds put scala way ahead, but I think you forgot the most important of all -- unification of call-by-name values with values. In short, one language is for "lolz", the other is for doing practical work. - Tony Morris
(4) Don't you think Scala's special handling of apply & companion objects substitute for syntactic sugar of <insert-any-collection>? - Daniel C. Sobral
(25) +1 for "it exists". Existence is very persuasive. - Apocalisp
@Tony - I agree it's important; I had lumped that not-entirely-technically-correctly under "trivially easy closure declarations". @Daniel - Good point; I'll add that. - Rex Kerr
No traits. No type inference. No lambdas. No imports. No implicits. - Sciss
Scala has 10 years behind it plus the experience of Odersky. It's recently commercial with Typesafe and we'll see Akka integrated. A noble effort and competition is good, but... - andyczerwonka
[+20] [2011-04-14 10:57:06] oxbow_lakes

As I read through the Ceylon presentations yesterday, I was astounded by how much Scala is already providing a solution for those issues which Ceylon claims to be addressing (with respect to shortcomings of Java).

In fact, I'd say that pretty much 95% of what Ceylon appears to be trying to accomplish, can already be done with Scala. (The obvious exception being union types).

So that means that the Ceylon designers, for a 5% feature difference, have decided to design a whole new language from scratch - an astonishing decision. As Daniel mentions above, getting scala to the stage where it's at now, with good IDE support and a number of useful frameworks providing library solutions to such areas as web-development and concurrency, has taken > 5 years. 5. YEARS.

If you add-in the most obvious concerns about Ceylon as a language:

  • Java interop is going to suffer (no overloading, wildcards, reified generics, no null etc)
  • Lack of academic grounding & conceptual simplicity
  • Lack of implicits

For the extra 5% features you are sacrificing a lot of good stuff.

And for Gavin King to claim that it is conceptually simpler than Scala is breathtaking. From everything I've read so far, it looks a lot like a wish-list of minor functionality crammed awkwardly together, whereas Scala generates its power and scope from its simplicity.

In the comments on this blog post [1], Gavin mentions "extra features" as being more complex. But of course that is not necessarily true! Or rather, it depends stroingly upon your definition of an "extra feature". For example, you could argue that the ability to declare a value which is a type is an extra feature and therefore represents an addition of complexity. But, conversely, you could equally argue that treating types differently to values (i.e. disallowing them as values) is adding complexity (because it represents the "addition" of a feature, namely the special treatment conferred upon types). Similarly with higher-kinded types: why should a type parameter not also be allowed a type parameter? Why is that more complex?

EDIT - on additional comment is that Gavin King explicitly criticises Java because of its lack of declarative GUI tools. He has presented nothing to suggest at exactly how Ceylon addresses these issues, so I do wonder whether he's got something up his sleeve on this one. In fact, I strongly suspect that final judgement should probably be reserved for when a working prototype is available!


In order to have good declarative GUI tools, you need first-class functions and a nice hierarchical syntax for declaring objects. Gavin mentions both of these as features in his introduction to Ceylon. - Gabe
(1) Actually, I did see something that looked to be his solution to GUI prototyping. It looked a lot like a declarative-style DSL. Reminded me of Scala Swing (minus Java Swing's anchor). - Daniel C. Sobral
The slides are pretty unimpressive. The only thing that could be interesting for Scala IMO is the idea of union types. Imagine: def perform( t: A or B ) (to accompany t: A with B) -- you could call anything straight on t which is a member of both A and B, and for the rest you would use an exhaustive pattern match. Maybe in Scala 3? That way overloading could be removed :) - Sciss
(1) @Sciss - def perform(e : Either[A, B]) would about do it - oxbow_lakes
(1) @Gabe - yes, I was wondering whether this "declarative" style (similar to JavaFX) was solely what Gavin meant. If so, scala haz dem! - oxbow_lakes
@oxbow: The "declarative" style is certainly what he's talking about because he has an irrational fear of XML. I'm pretty sure that it's really first-class functions that are needed, though, because when MS got in trouble back in 1998 it was due to adding delegates to J++ in order to make GUI codegen easier. - Gabe
@oxbow_lakes - Either is OK sometimes, but for one you need to pimp it to accept A or B straight away. It looks ugly, and it doesn't scale when you need view bounds like A1 <% A, and it doesn't scale to A | B | C and so forth. Finally, how about higher kinded types, such as List[ A or B ]? We already have like a type intersection with A with B with C, wouldn't it be consequent to allow for type unions such as A or B or C? - Sciss
@oxbow_lakes p.s.: seems it's coming eventually: -- probably earlier than in ceylon :))) - Sciss
[+14] [2011-04-13 14:35:32] Daniel C. Sobral

I haven't read anything about Ceylon yet, so let me comment on your check points.

Scala does better:

  • Type inference via the "local" keyword

    Scala's very syntax was designed to make type annotations optional everywhere; it does require type annotations on method parameters and return value of recursive methods or methods that use return to break evaluation, but if a good type inference algorithm was designed to handle that, no modification would have to be made to the language's syntax.

  • Straight-forward implementation of higher-order functions

    Scala provides higher kinded type inference as well, which is very important in a functional statically typed language.

Scala has:

  • The overall vision: learn from Java's mistakes, keep the good, ditch the bad

    It is worth noting that Odersky, Scala's creator, co-designed Generic Java [1] -- which became Java 5's generics -- and Pizza -- a language created to mix functional aspects with Java. That means Scala is not only a result of that vision, but a result of previous iterations of that vision. See more about that history here [2].

  • Static Typing (find errors at compile time, not run time)

  • No “special” types, everything is an object
  • Named and Optional parameters
  • No need for explicit getter/setters until you are ready for them
  • Nullable types

    Actually, nullable types are Optional types, just like Scala's Option. From Gavin's blog, they are similar to Haskell's Maybe, which is also the origin of Scala's Option. From InfoQ [3], there no null in Ceylon. This is a big advantage for people wanting reliability in their programs, but a major drawback for interoperability. One of Scala's goal was interoperability, which is the reason it has null.

Scala intended, but many people claim it hasn't achieved:

  • The focus on readability
  • Ease of learning/use

    Actually, I think it does pretty well on readability, once one has actually learned the language. The learning curve starts shallow too, but gets steep further on.

Not sure:

  • Sequences (arrays) and their accompanying syntactic sugariness

    One can write things like Set(1, 2, 3), Array("a", "b") or val list = a :: b :: tail. This is not because Set, Array or List are given special treatment, but just syntactic sugar Scala allows any class.


So, I have read about it. I think the ideas behind Ceylon are good -- in fact, they are pretty close to the ideas behind Scala.

The two most striking differences between Scala and Ceylon -- in my own opinion -- is the lack of implicits, and the syntax much closer to C++ than Scala (and even Java, I think).

The absence of implicits reduces complexity a lot, which is nothing to sneer at. By the same token, it makes the language less capable. Implicits makes libraries easier to use, increase the value of static typing, and helps the creation of DSL.

I personally prefer Scala syntax over Ceylon's -- it looks cleaner to me, but Ceylon will certainly be more familiar to Java and C++ programmers.

These are two very valid design decisions. I prefer Scala's choice for both, but taste is very much an individual matter.

I didn't see them crediting any other language, which gives the impression of being a blind effort, but that may not be the case at all. The lack of a running compiler and libraries is much more concerning to me -- Scala takes hell for being "IDE poor", even though it has probably the second best IDE support in the JVM space. I shudder to think how much effort they have ahead of them.

On the other hand, Gavin "Hibernate" King is behind Ceylon, so I expect the effort to have some success, at least.


(2) I don't know about the very last sentence. Hibernate is a library. That's way easier to create than a language, compiler, SDK. - huynhjl
Ceylon's nullable types are also Option types, but use the nifty T? as an abbreviation for Optional<T>. - Gabe
(1) @huynhjl I'm not as concerned about simple complexity as I'm about proven record of actually delivering working code. - Daniel C. Sobral
@Gabe Nullable types don't look monadic to me, which is a big difference. - Daniel C. Sobral
@Dan: It's not if they're monadic, but at least they are typesafe. - Gabe
@Gabe From InfoQ and Gavin's blog, it looks like they are monadic indeed, with String? being syntactic sugar for Optional<String>. - Daniel C. Sobral
[+6] [2011-04-13 14:11:13] irreputable

Gavin King's motivation seems to be quite transparent.

Java frameworks suck big time for contemporary applications (mostly web+db). Java syntax is just not equipped to model these things concisely and elegantly. Java frameworks are constantly accused for being hideous looking. Some really deserve it; some don't - the author has explored everything he can to make it easy to read/write, but he's eventually constrained by the Java syntax.

Gavin yearned to tweak Java just enough so that his frameworks look elegant in the modified language.

I agree with this approach. Design a language to best solve contemporary problems. Very practical.

Update after seeing Gavin's blog [1] ( cached here [2]):

[...] the number one technical problem that we simply can't solve to our satisfaction in Java [...] is the problem of defining user interfaces and structured data using a typesafe, hierarchical syntax.


But much of our frustration is not even with the Java language itself. The extremely outdated class libraries that form the Java SE SDK are riddled with problems. Developing a great SDK is a top priority of the project.

I'm not sure about the 2nd one. It's easy to accuse, for example, that Java collections don't even have readonly interfaces. But it's unclear which design is best for practical use, unless they are tested in real world applications. Sometimes stupid and retarded design outshines smart designs in practice.

In any case, good luck. The amount of work is simply astonishing if they want to fix the language AND design a new SDK (AND a lots of other things too if a modern language wants to get some legs)


[+2] [2011-04-17 10:02:43] v6ak

Ceylon seems to be more conservative (in some ways) and more Java-like than Scala.

However, they have decided not to be fully Java-interoperable. (I currently don't know details about Ceylon <-> Java interoperability.) It looks strangely.

There are some differences: * Ceylon seems to allow to name some subexpressions. It can be useful in a declarative UI: you can do it really straightforwardly. * While Java has nulls and Scala supports them mostly for backward-compatibility reasons (but Scala has also Option), Ceylon does not have nulls in traditional sense. It sounds great until you realize that this is a problem when interoperating eith Java. * Generics: Java has simple generics with type erasure. Scala has more complex generics with type erasure, but you can bypass the type erasure by implicits and Manifest. Ceylon will have some generics (I don't know how much advanced they are.), probably with no type erasure. This will be probably another Ceylon's interoperability issue in Ceylon. In Scala, you can do this probably without any serious issue.

In fact, I like Scala and I don't have many reasons to switch to Ceylon. But there are two positives:

  • It can be great for GUI. (However, the feature can be probably implemented also in Scala if it hasn't been implemented yet.)
  • If it succeeds, it can help to break problems with nulls on Java platform.

[0] [2011-04-15 23:11:43] John

It looks like they are going to ditch Swing and go with a web GUI. In this day, this might be advisable. However, I would be curious how they are going to deal with Browser dependencies. The "new SDK" might have a lot of misfeatures/bloat for dealing with various browsers. What is Ceylon's plan?