Time for tea?

Another day, another Java menace: Ceylon has landed

This week’s Devoxx conference in Antwerp saw the launch of two box fresh languages: Google’s Dart SDK 1.0, and Red Hat’s Ceylon 1.0. From the start, many have tipped Ceylon as a clear threat to Java’s platform (the clue is in the name). But is it really Red Hat’s intention? Creator Gavin King has been adamant from the earliest development stages that the intention has always been to create something that can run alongside Java - but designed as a language and SDK for business computing that learns and builds on Java’s successes and failures. We caught up with King for the full scoop on this week’s launch, the work behind it, and what’s brewing next at Red Hat towers.

JAX: First of all, congratulations on the launch of Ceylon at Devoxx this week!

King: Thank you! There was certainly a lot of buzz at the conference - that's really nice for us.

What was the impetus behind the development of Ceylon?

Obviously, at the time when the language was first conceived, I was doing a lot of work with the JCP on the Java EE side of the platform, and had been working for several years with certifications like EJB, and CDI, and some of the other technologies on the platform. And, you know, especially during a period when I was working on CDI, at some stage, I got to the point where the incremental improvements we were making to the programming model and to the experience of our users was - how can I say - a sequence of diminishing returns.

The problems that I was becoming more interested in, and which were really frustrating me more, I suppose, were things that were more at the language level. The limitations which I was bumping up against were things which I couldn't solve at the library framework level.

So it started, I guess, as a set of ideas for how could we enable a better programming model - and, especially a better programming model for people who were building frameworks and libraries and more generic code. Obviously, since that time, the concept has evolved in different ways, but I guess that's still very much part of it.

What were the biggest problems that you were looking to solve with this project?

Well, one of the biggest limiting things was the fact that, as soon as you wanted to define a user interface or some kind of structured data set configuration, or anything like that, or build, or anything like that, in the Java world, you had to leave the language of Java and go and use some other language, say XML.  And it was even worse if you were writing a user end code for the web browser, because the whole, ‘write once, run anywhere’ thing kind of failed immediately.

Java has been enormously successful, wonderful, fantastic language - but, the initial vision kind of failed on arrival. And so, as soon as you wanted to bridge the gap to a web based client, you found yourself having to leave the Java language and write something in JavaScript or something like that. Java applications today are composed of several languages cooperating together, and that's not necessarily a bad thing, but the problem is that you lose static typing, you lose the tooling support.

Java developers like me are amazingly attached to having great tooling, and having tools that help us maintain and refactor and alter our code. As soon as we leave Java and start having to work with XML or JavaScript, we really keenly feel that loss of support from the tooling level.

Going back to the feedback that you've had this week - a lot of commentators are calling Ceylon a "Java killer." This is something that you've denied in the past, but can you see why people think this?

Well, I mean, Ceylon certainly competes with Java as a language, obviously, and we go even further than that. Nor merely a language, but also a set of platform libraries. And so...it's a competitor in some sense, but I mean, it would almost be absurdly arrogant of me to say, “we're going to go up and compete against Java”, which is an amazing ecosystem of multiple technologies that work together.

You know, I prefer to think of it as being part of the Java ecosystem, right? Sure, we go beyond that Java ecosystem in terms of operating also in the JavaScript environment - but you know, we think of ourselves as part of the JVM ecosystem, along with other languages.

For us, interoperability with other languages, beginning with Java and JavaScript - but I hope to extend that to interoperability with JRuby, and with Groovy - we want to be part of that world, and work together with other technologies. I expect that, realistically speaking, any Ceylon application is going, in the near future, to be composed of a mixture of Java and Ceylon and JavaScript, quite frankly.

Although you're saying that it's a kind of complimentary rival, why did you decide to name it Ceylon?

Well, Ceylon started off as the name of a secret project inside RedHat. It's a play on Java, and Java is an island in Indonesia which was a source of coffee during colonial times, and Ceylon was another island in the Indian ocean that was a source of tea. So it comes from that - it was a play on that.

It was never meant to be the name of a programming language, but it kind of stuck. When I proposed to change it, and said, we'll come up with a real name, my colleagues turned round and said, "no, no, no! We like that one! Don't change it," so....

Naming issues aside, what was the most challenging aspect of developing Ceylon?

I mean, obviously, it's been four years of extremely hard work and it's an enormous undertaking and software engineering challenge. There have been many hard parts of it.

Designing a type system for a statically typed language, you know, if you want a state of the art statically typed language these days, the conceptual work that goes into the design of a type system - really a lot of quite technical and deep thinking needs to go into that, and that occurred over several years.

In terms of actual development and writing code, by far the hardest part of what we wrote was the part of our compiler which takes a model of the Ceylon code and turns it into an abstraction for Java, that Javac can take off and generate code for the JVM with, that transformation, that mapping between the Ceylon language, and the model of the JVM users. It was definitely the most challenging part, and we're immensely relieved to have finally got it done. That was really the thing that took two years to do.

So now the hardcore tooling is done, what are your plans for future releases?

The Ceylon 1.1 release will be all about performance enhancement. We wanted to get a working release of the language out as soon as possible, and we we didn't have time to concentrate on some performance related issues. So the next release, which we plan for about three or four months in the future, so early next year, will be about performance optimisation as opposed to the resulting code that we generate, and also to our compiler, especially build performance within our IDE.

That's something that's very important to developers when they're writing and building code within the IDE - that it be snappy and fast, and we have work to do there.

Secondly, the shift of emphasis from development as a language into development of the libraries and frameworks that people are going to use to build applications with. Obviously we have some things there, some basic things, but now there's going to be a whole load more of work going on there. Already much of our SDK has been built by external RedHat community contributors, who've popped up and been really interested in one particular problem, say the build system. And there will be more of that, and there's going to more investment from Red Hat in that stuff, and naturally that's going to involve lots of people from outside the Ceylon team.

Ceylon does look a lot like Java - when compared to other languages on the JVM, what do you think makes it stand out?

I guess at this level of conversation, there's three things I always point to. First of all, most of the languages for the JVM are dynamically typed, or most of the popular ones are, so there's the fact that it's a very statically typed language, very type safe, more than even other statically typed languages.

Secondly, Ceylon has built in modularity, which is something that Java has been promising for a long time, but the latest news from Devoxx is that essentially, the plan to provide modularity to users of Java, to a Java application, has been abandoned and that, if we're understanding correctly, the current modularity of the Java platform will focus solely upon the Java SDK itself. We had been expecting originally Java 8 to provide modularity at a platform level, and that hasn't happened, nor does it look like it's going to happen anymore. Ceylon offers at this point, uniquely, modularity based in that language level, pooling them into the IDE and the runtime.

Making use of modules and so on is so much easier than any of the other options you have available to you. As a result of that, if you were to set up a Java application that used Maven and OSGI and Eclipse together, if you were to try to do that, it would take you a week of lost productivity to make that work. Whereas with Ceylon, you get it for free.

Aside from that, we have a really special type system. It's simple, but very expressive and powerful, and we think people are really going to love it.

Finally, going forward, do you think that going forward, Red Hat will start coding more in Ceylon?

The first step for us will be to bring some of our pieces that we have in the JBoss ecosystem that we delivered as pieces of the application server, and repackage them, and make them modular, and make those modules for the Ceylon platform.

At the same time as that, we're taking Ceylon, and we're enabling deployment to Openshift. Once we have then the capabilities that we have in JBoss, also for Ceylon, then it's going to be a lot more interesting - what can we do in Ceylon that we can currently do in JBoss?

People often ask me, does RedHat use Ceylon to build internal projects, and I'm always kind of like, I don't quite understand, we don't have internal projects, we're a product company!

Image by Christian Cable

Lucy Carey

What do you think?

JAX Magazine - 2014 - 03 Exclucively for iPad users JAX Magazine on Android


Latest opinions