Performance Zone is brought to you in partnership with:

e-Commerce consultant, specializing in agile project delivery, security and identity management, cloud-based analytics and social media integration. Akber's experience is over two decades of solution delivery, from the AS/400 to J2EE and enterprise architecture. Akber has posted 2 posts at DZone. You can read more from them at their website. View Full User Profile

Is Ceylon Enterprise Ready?

10.04.2013
| 13142 views |
  • submit to reddit
Not since GW-Basic printed "Hello World" on an IBM PC-AT have I been this excited about a programming language.  OK, there was Java and the servlet API!  Taking Ceylon for an extended spin over a couple of months on a real life project, the language appears to address the three items on the wish-list of any enterprise software development: end-to-end type safety, built-in modularity and an elevated syntax that eases re-factoring and maintenance of enterprise projects.

Although quite young (just released 1.0-beta), Ceylon holds a lot of promise in these very areas. Watching its development, it is clear that the arcane complexities of type theory are routinely decomposed into abstractions that a developer may never interact with, but it allows her to say more, more clearly – the motto of the language. More than just a slogan, it seems to be the guiding philosophy of the language and the lead, Gavin King (of Hibernate, Seam and CDI fame) has stuck to the specification and its lofty goals

Backed by RedHat, Ceylon is enterprise-ready.

A Subjective Comparison

Ceylon builds on top of Java, has bidirectional interoperability with Java (and even Maven) but is not a drop-in replacement for individual Java classes.

Java is the beloved old workhorse and its strictures and sober evolution have managed to bring library breadth, security and stability to enterprise development and inspired C# and many other languages. Java was the rightful heir to C and innovation in Java was reluctantly pushed on it by those who stretched its strictures.  That was the state of affairs before open-source was fully accepted.

Java's strength became its weakness in an open world.  Scala brought new theoretical constructs to the JVM and forced us to clearly distinguish between Java and the JVM. Its strength and weakness is that it is a drop-in replacement for Java.  Let's not provoke a flame war by commenting on its syntax! In my opinion, Go and Kotlin are still making it up as they go along.

In the non-JVM world, PHP, Ruby, and now server-side JavaScript, are the favorites of startup Web development, and they have all broken new ground in ease of adoption, web savviness, fluency and composability. Despite PEARs and gems, type safety and modularity are policed by the discipline of wizard programmers and not by the constructs of the language.  However, in the enterprise, built-in discipline and modularity is needed by the ranks of enterprise programmers delivering on tight budgets and deadlines.

Do you see where I am going with this? As with any language, strengths become weaknesses unless strictly constrained by force of character.  Ceylon promises to have that character, and if it develops an easy on-ramp for all levels of developers and sticks to its guns, we will be hearing a lot more of what can be said in it.

Technical Features

You will find a lot of the details on the website, but let me quickly recap the high-level technical features that I think developers, and their employers, will love:

  • The declarative syntax and static top-level objects and functions can be intuitively used from basic scripting and templating to building the most abstract of frameworks.  Once the ecosystem develops, Ceylon modules might be all that you need.
  • While a developer is concentrating on programming a solution to a business problem, Ceylon provides the kind of sure-footedness that is reminiscent of fast German cars. As you code, you naturally know what your variables are, their state and what they can become. The strictures of the language do not allow null-pointer exceptions or class-cast exceptions. The up-front time investment is immediately rewarded by fluency (despite a lot of indent levels), but the real reward is when you are pleasantly surprised that a major re-factoring resulted in just a few logic errors -- and no wiring errors.
  • Type manipulation.  Want to send back two objects from a function?  No problem, No need to wrap them in a holder ‘bean’ – just intersect/union them, or put them in brackets.  Want to accept a random iteration of many different types as a parameter, with at least one element?.  Just 'or' the types with a + at the end. Soon, the natural flow grows on you.  And once you have made an initial mess with all kinds of types floating around, re-factor to your heart’s content and the language will guide you along.  If the type definitions become too complex, alias the expression with a nice name.  Basically, Ceylon doesn't get in your way while the creative juices are flowing and then gives you the tools to mop things up nicely with its extremely sophisticated under-the-covers type wizardry.
  • Although compile-to-build-to-deploy modularity will continue to evolve, it is already ahead of what Java Jigsaw may offer next year.

The community around Ceylon is disciplined, agile and hyper-excited. That leads to quick and solid feedback to issues and any last-minute changes before 1.0.

Ceylon should be a definite consideration for when you question what framework or language you are going to use for your next enterprise project.



Published at DZone with permission of its author, Akber Choudhry.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jean Said replied on Fri, 2013/10/04 - 6:59am

 Just so that you know beforehand: they have firm plans to leave the JRE platform and implement their own alternative, with their own framework. It's not a "maybe" it's more of a milestone.

That's JBoss for you.

The language is nice, but they want to reinvent their own wheel. Let them do...

Tako Schotanus replied on Fri, 2013/10/04 - 8:01am in response to: Jean Said

As one of the core Ceylon developers I can assure you that's not true. Our whole strategy is based on the fact that we love the Java platform and eco-system. We go through a lot of trouble to make sure that we have complete interoperability with existing (and future) Java code.

If there's one thing that you could call "implementing our own alternative" it would be our SDK, but that's the basis that the language is built on, we want to provide something better than what you get with Java, but everything in the JDK will be available too. You decide what to use, not us.

Bob Smith replied on Fri, 2013/10/04 - 8:20am

"Just so that you know beforehand: they have firm plans to leave the JRE platform and implement their own alternative, with their own framework. It's not a "maybe" it's more of a milestone."

Evidence, please?

Gavin King replied on Fri, 2013/10/04 - 8:24am

To reiterate what Tako just said: continuing to support the JRE and providing interoperation with other languages that share it is of utterly crucial importance to the vision for Ceylon. We are utterly committed to providing excellent interop with Java and the Java SDK, and in future you'll probably see interop with other JVM languages like JRuby and Groovy.

That Ceylon additionally targets a second runtime environment, namely JavaScript virtual machines, does not in any way subtract from our commitment to the JVM.

We have no plans to implement any kind of Ceylon-specific virtual machine.

And yes, precisely, "that's JBoss for you". JBoss has a history of commitment to the Java platform, to the JCP standards, and to portability. We reuse or support existing standards wherever reasonable, and contribute our innovations back to the standards bodies when possible. I personally dedicated at least half of my working career to the JCP, and my original ideas can be found in 6 different Java EE specifications.

Hope that helps.

Bob Smith replied on Fri, 2013/10/04 - 8:30am

BTW, agreed on all points in the article/blog. Ceylon has all of the advantages going for it, relative to its era, that Java 1.0 had relative to its era in 1995/1996. Ceylon has a greater advantage in that it's not being rushed to market the way Java 1.0 was. For all intents and purposes, it deserves to become the heir apparent to Java as the lingua franca for enterprise development. The only question is whether or not this actually happens.

Jean Said replied on Fri, 2013/10/04 - 3:32pm

Well these are good news. The Ceylon presentation in Paris really turned me off... it was definitely not clear. I really hope that these online people are as real as the Devoxx ones...

Well, this was not the only thing that put me off, it's also a language philosophy thing, but still nicer that the maybe misleading presentation.

Akber Choudhry replied on Fri, 2013/10/04 - 3:55pm

No worries Jean.  Gave the team an opportunity to clarify.  Please do discuss, as philosophy is important.

Mansur Ashraf replied on Fri, 2013/10/04 - 7:10pm

what advantage does it bring over Scala? Not trying to start a flame way but genuienly curious why someone invested  in Scala should look at ceylon

Akber Choudhry replied on Fri, 2013/10/04 - 9:51pm

Well, as the Kotlin overview page says, if you are comfortable with Scala, stay with it -- it shows  a respect for Scala within the community. All of us have our subjective opinion and mine is based on the perception of how enterprise business applications are built and maintained -- and the skills and deadlines they have to work with.

From a purely technical perspective, Ceylon takes OO, reified generics, operator polymorphism, first-class functions, and type intersection, union and aliasing to their natural evolved state -- without sacrificing the ability of enterprise programming teams to make do with the resources that they have. In simple words, get the best that technology has to offer without sacrificing what made C, and subsequently Java, a staple in business development -- ease of on-boarding and maintenance.

Ceylon does all that in a way that values purity of design over the ability to drop-in into Java code seamlessly.  It may be riskier, but I think it is the next step in a focus area: the way we program, deploy, and maintain, business applications in the enterprise.

Gavin King replied on Sat, 2013/10/05 - 3:19am in response to: Mansur Ashraf

Hi, Muhammad, that's definitely not an easy question to answer, because the two languages are different in so many ways. They're similar in that they both belong to a bigger class of languages including C#, Java 8, and others, that is characterized by:

  • static typing
  • lexical scoping
  • a syntax ultimately derived from C
  • the combination of subtype polymorphism and parametric polymorphism ("object-oriented" with "generics")
  • functions are values (including anonymous functions) 
  • runtime metaprogramming with annotations and reflection
  • garbage collection, no pointers
Furthermore, both Ceylon and Scala can execute on the Java virtual machine.

Beyond this, there are only superficial similarities between the two languages. I would say that Java and C# are much more similar than Ceylon and Scala.

We tried to boil down what makes Ceylon distinctive in this feature list, but this list is in itself kinda superficial. I guess I would draw your attention to:

  •  the central importance of modularity, and especially how it becomes a foundation for cross-platform execution (by which we mean, JVM/JavaScript) via the minimal core language module,
  • the importance attached to readability and omission of language features that can be too-easily abused,
  • some distinctive features of the type system, like union/intersection types, flow-dependent typing, and our treatment of function and tuple types, and
  • how the combination of reified generics and the typesafe metamodel clean up the whole big area of runtime metaprogramming.
I hope that gives you some kind of an answer, without delving into flamewarish areas.

Stephane Epardaud replied on Mon, 2013/10/07 - 2:49am in response to: Jean Said

Hi, I'm one of the guys who did the presentation at Devoxx France, which I guess is the talk you're talking about?

If that's the case, can you tell me what I said that wasn't clear or led you to think that we would ditch the JVM? If I wasn't clear on something I need to do better next time :)

And yes Tako and Gavin are in the same team as I am working on Ceylon so I can assure you they're as real as me ;)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.