What's the difference between Scala and Red Hat's Ceylon language?

Question

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

• The overall vision: learn from Java's mistakes, keep the good, ditch the bad
• The focus on readability and ease of learning/use
• Static Typing (find errors at compile time, not run time)
• No “special” types, everything is an object
• Named and Optional parameters (C# 4.0)
• Nullable types (C# 2.0)
• No need for explicit getter/setters until you are ready for them (C# 3.0)
• Type inference via the "local" keyword (C# 3.0 "var")
• Sequences (arrays) and their accompanying syntactic sugariness (C# 3.0)
• Straight-forward implementation of higher-order functions

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

How would Scala compare to Ceylon in this respect?

Answer 1

I assume you read the same Slashdot article 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.)

Update: Scala 2.10 has syntactic sugar for strings (in a general way that lets you define your own string-like language features).

Answer 2

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

Answer 3

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

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

EDIT

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.

Answer 4

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 (cached here):

[...] 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)

Answer 5

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.

Answer 6

I started using Scala this year, and really like it. I've also attended a conference by Gavin King and talked with him about Ceylon. The idea is to have an enterprise-level replacement for Java. Some of the key features of Ceylon (not all of these exist yet) are:

• It is intended to be used for large projects involving large teams; readability is very important, since in large projects you can spend more time reading other people's code than writing your own.
• Everything is an object
• There is operator overloading BUT it's not arbitrary. For example if you want to implement "+" in your class, it must implement the Summable interface. EDIT actually this is called operator polymorphism, not overloading...
• Union and intersection types. This is BIG, one of my favorite features of the language and I haven't seen it in Scala or any other JVM language (actually I don't know where Gavin got it from but it's one of those things that I would like to have NOW in Java or any other language).
• Everything is immutable by default, but of course you can have mutable objects by adding the "variable" keyword to your declarations.
• Built-in builder pattern which creates immutable objects
• No nulls by default. If you declare "String x" then x can never be null; if you want x to be null at some point you have to declare it as "String? x", and then every time you want to use x you have to guard it like "if (exists x) {bla} else {bla}"
• The generics are much better than in Java, thanks to union and intersection types.
• No method overloading (not needed, because of union and intersection types).
• Local type inference (ONLY locally)
• Null is type-safe
• Java Interop (it's not there yet, but you'll be able to use Java classes from Ceylon, and you are able to use Ceylon classes from Java today)
• A completely new module system. This will solve many (or hopefully all) of the problems that are today managed by Maven/Ivy and even OSGi, dependency-wise.
• Interfaces that can have concrete members (similar to Scala traits, but Ceylon's interfaces can only have methods, no state).
• Top-level functions and higher-order functions.
• String interpolation
• Two levels of visibility for classes/methods/properties/etc: shared and private.
• Default values for method/function parameters
• Singletons similar to Scala, by using "object" instead of "class"
• Declaration-site variance and generic type constraints

EDIT some other features I missed the first time around:

• Algebraic types
• Its own SDK (language module with all the basic classes and functions)
• JVM and javascript backends

---

Union and intersection types allow you to do stuff such as:

• Declaring variables/parameters/return types that can accept two or more different types. You can have a method such as "print(String|Int p)" and it can receive either type, or "write(Cloneable&Serializable p)" and it can only receive types which implement both interfaces.
• Heterogeneous collections. You can have a List to store objects of either type. Or a List to accept only types that implement both interfaces.
• Generics are actually much better and simple because of these types. Instead of having stuff such as Java's "?-capture-of" which practically nobody understands how to use, you can just declare the types you need.