Red Hat Uncloaks 'Java Killer': the Ceylon Project

talawahdotnet writes "Gavin King of Red Hat/Hibernate/Seam fame recently unveiled the top secret project that he has been working on over the past two years, a new language and SDK designed to replace Java in the enterprise. The project came out of hiding without much fanfare or publicity at QCon Beijing in a keynote titled 'The Ceylon Project — the next generation of Java language?'"

Comments

No need to duplicate work

[MrEricSir]

We already have a Java killer; his name is Larry Ellison.

Re:No need to duplicate work

[Anonymous Coward]

One Rich Asshole Called Larry Ellison.

Poetic.

Java killer?

[PCM2]

A "Java killer" that relies on the JVM to run sounds like it's in for an uphill battle.

Writing an SDK from scratch in a homebrewed language that does everything the Java SDK does? Well, good luck anyway.

Re:Java killer?

[PCM2]

if enough people decide it is a good idea and participate, it may take much shorter than you can imagine.

Designing and implementing a new programming language that's intended as a direct challenge to Java... by committee... using a distributed development model... "much shorter than I can imagine"? Have you followed the history of Java at all? Or of any language?

linux prevailed, firefox prevailed.

And both were written in a language people already knew.

Re:Java killer?

[ceoyoyo]

A new language that relies on an x86 processor to run sounds like it's in for an uphill battle....

There's no reason not to use the JVM. It's a highly optimized, widely distributed virtual machine (just like x86 processors are highly optimized, widely distributed actual machines).

Now Java as a language... leaves something to be desired.

Re:Java killer?

[raddan]

My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language. The JVM actually isn't all that bad-- it's mature, bug-free, and reasonably fast. But that's beside the point-- the JVM is like x86. Nobody* cares about the instruction set; they care about language features, and whether those features work quickly. And both the Java VM and Microsoft's .NET runtime have numerous options: IronRuby for .NET and JRuby for JVM, IronPython for .NET and Jython for JVM, Clojure, F#, yadda, yadda.

Reinventing the VM is a waste of time. And there are tons of languages to choose from for those VMs. So I don't quite see the point of this. The slides appear to be slashdotted, and just from the post's talking points... yawn.

* "nobody" here should be read as "very few", i.e., mostly people who write JIT compilers and not people who write enterprise code.

Re:Java killer?

[cakoose]

Any experienced c++ programmer will tell you that "classes if necessary, but not necessarily classes" is the way to go. Class explosion is not pretty, and makes for over-complex stupid implementations.

When trying to design a new, clean, high-level programming language, I probably wouldn't pay much attention to C++ rules of thumb.

Making everything behave like an object can make things much cleaner. It all depends on how exactly this is done, but a lot of complexity in Java comes from the fact that primitive types behave differently. C# did a bit better, but there's still the value-vs-class distinction which can trip you up in subtle ways.

Re:Java killer?

[jensend]

Kill off interfaces (even James Gosling admits that they were probably a mistake), add multiple inheritance.

*citation needed*
Everything I've seen from Gosling says that pure interfaces are the way to go- even to the extent of getting rid of regular inheritance; see these quips. I don't think anybody who's seriously looking at language design thinks C++- style multiple inheritance is a good idea. Nor does anyone want to resurrect the braindead C preprocessor way of dealing with things.

And what's so bad about :=? The fact that some outmoded languages used it doesn't make it a bad idea. Most of us are familiar with its use as a definition or assignment, and avoiding confusions between = and == could be a plus, especially if (as he seems to propose) the latter is extended to replace use of .equals().

Re:Java killer?

[Mongoose Disciple]

why not ? if enough people decide it is a good idea and participate, it may take much shorter than you can imagine

I don't think you grasp how much Java stuff is out there already, even open source, and how many years it took to produce.

Open source isn't like a magical brownie cobbler that fixes your shoes in the night if you leave him a little saucer of milk. Sometimes it duplicates its effort, so to speak, for no good reason but I wouldn't bet on it on a massive scale any more than I'd bet on winning the lottery, except someone actually does typically win the lottery.

Re:Java killer?

[cakoose]

My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language.

C# started out essentially the same as Java. But at this point it's way better.

• Function types and closures. This alone makes it way better.
• More efficient generics (no boxing/unboxing).
• Local variable type inference.
• Coming in C# 5.0: automatic CPS transformation (async/await).

Re:Java killer?

[clang_jangle]

now, not only we are mature, but also we have endless number of tools to facilitate distributed development.

There's some truth to that, but it also reminds me a bit of my eight-year-old neice talking about how different everything is now compared to way back when she was seven. :)

Starting to show indications of maturity yes. Achieved maturity -- not quite yet I think.

Re:Java killer?

[shutdown -p now]

My favorite part about the post is that he points to C# as an example of a "good" language, as if C# and Java were not essentially the same language.

They aren't. C# 1.0 was essentially Java with syntactic sugar, yes (properties, events, delegates, enums, varargs, ...), but syntactic sugar can make a lot of difference in practice for readable and understandable code. It also had some nice parts such as unsigned types, stack-allocated user-defined value types, and raw pointers - all that mostly useful for efficient interop with C libraries, but it's a surprisingly common scenario even today.

C# 2.0 added iterators (what Python calls "generators" - functions that produce a lazy sequence of values using some nice syntactic sugar), fully typesafe generics (no type erasure), and, most importantly, full-featured closures. A minor addition were nullable value types (unlike Java, you use strongly typed box types like Integer for the same, C# nullable value types are not boxed and therefore do not require heap allocation).

C# 3.0 added type inference for local variables, array literals, and closure return/parameter types; and sequence comprehensions (rebranded as "LINQ"). Minor additions were tuple-like anonymous types - "new { foo = 1, bar = 2 }"; and array-like literals for arbitrary collection types - "new List<int> { 1, 2, 3 }".

C# 4.0 added "dynamic" type, which is essentially opt-in duck typing. Another big addition is covariance and contravariance for generic type parameters - making e.g. "IEnumerable<Object> objects = new List<string>()" valid. Minor additions are optional method arguments, and named (what Python/Ruby calls "keyword") arguments when calling methods.

For comparison, in the same time period, Java has added a half-hearted generics implementation, enums, and vararg methods.

So, no, they're not the same language anymore.

Re:Java killer?

[RzUpAnmsCwrds]

Anyone who wants Java to allow overloading of == clearly has never had to deal with C# code (C# allows overloading).

The fundamental problem is that people don't understand Java semantics. In Java, equality testing is consistent and efficient: for reference types (everything except primitives), == always means reference equality. And .equals() always means value equality.

Comparing strings with == sometimes works because the runtime allocates string constants from a pool. So ("A" == "A") evaluates to true because they reference the same object. But ("A" == new String("A")) evaluates to false.

The key here is that object variables in Java are *always* references. That's why any object reference can be null, and it's why you can't compare them with ==.

The problem with overloading is that it's not consistent. Some C# objects overload ==, some don't. There's also ".Equals()", which always checks for value equality. There's also the static method Object.ReferenceEquals(), which always checks for reference equality.

So you end up with this trap where you either end up using Equals() all the time (as you do in Java), or you have some code that uses Equals() and some code that uses ==. Which doesn't make sense.

Java is about consistency and predictability. Having operators do different things in different contexts results in neither.

Re:Java killer?

[degeneratemonkey]

I absolutely hate Java, and I rather like C++, but I take serious issue with your ignorant, intolerant ranting...

1. GC implementation is not a language feature, it's a runtime feature. This has nothing to do with Java as a language. Furthermore, any sufficiently complex C++ program implements some form of (at least) semi-automated garbage collection; even if it's just reference-counting smart pointers. You apparently have no experience writing real software.

2. Really though, are you seriously arguing against non-deterministic GC because you think every program in the universe should be "well-behaved" and "provable" (on your own terms)? We might as well toss out, gee, I dunno, almost every modern language under the sun while we're at it. I think I can count on one hand the number of languages in regular, widespread use today whose standard runtimes leave memory management exclusively up to the programmer.

3. If you're really going to go down the "provable" road, you'd better throw away your C++ compiler too. Without referential transparency, C++ is practically useless as a language that facilitates "well-behaved" and "provable" code. Haskell for you.

4. "Class explosion?" This sounds like a term that would be used by a C programmer who writes C code inside of C++ classes, but who doesn't actually design object-oriented programs. "Classes if necessary, but not necessarily classes" would be exactly the kind of tripe I would absolutely never expect an experienced C++ programmer to say.

5. Meta-language (preprocessor/macros) is not language. Similar to point #1 in that it has nothing to do with the language itself. You could build a simple preprocessor for Java code if you felt so inclined (there are a small number out there already). It's a separate tool though. #define is not part of the C++ language in any way. It's part of the CPP language.

6. Kill off interfaces? No. What? I see problems with interfaces, but as a general idea they are not something to be killed off. Rather, I'd like to see the adoption of a more flexible "interface" system much like Go's. And multiple inheritance doesn't even make sense unless you like your objects to be schizophrenic, but please see point #4. The part about not understanding OOP.

7. Finally, you're cutting into a language like Java, while strongly defending an equally flawed language like C++. From your ranting it seems as though you don't understand either one (or many other languages, for that matter) well enough to comment on them. Yet here you are, vomiting invective upon the weary masses of Slashdot.

8. *Smack* Now go read something and stop face-rolling your keyboard. Thanks.

Oh and on-topic. Ceylon sounds interesting. I'll play with it. "Killing" Java will require billions of dollars though.

Re:Something to watch

[zill]

I personally don't think it's ambitious at all. Their syntax and grammar only differ slightly from regular Java. Plus the fact that they're targeting the JVM means that they only need to patch javac (and javadoc) to make a new language. Despite how humongous the JDK is, the java compiler itself is relatively lean (only 140KLOC).

Re:C#/Mono similar?

[Anonymous Coward]

Two words: Oracle.

What's the second word?

hmm.

[jensend]

1. Put these guys, Walter Bright, and a few other folks (Alexandrescu? a couple of the best folks from the Java and C# camps?) in a building.

2. Lock the doors from the outside and guard the building until they've come up with the One True C++ Successor (both compilable to native code and a good target for a JIT) and the basic design for its standard library.

3. Profit^H^H^H^H^H^H End the ridiculous situation we have where systems-level programming is held back by 40-year-old braindead technologies like the C preprocessor while the dominant business programming languages are controlled by corporations with terrible track records.

Re:C#/Mono similar?

[Megaweapon]

Two words:

Oracle.

What's the second word?

Lawyers.

Missing feature in Java: Copy on write

[Michael Woodhams]

My number 1 missing feature in Java is the ability to set object references to be 'copy on write'.

I'm doing numerical/scientific programming. Say I have an object which contains an array, and a 'get' function to return that array. Currently I have two choices: I can return a pointer to my object's array, or make a copy of the array and return that.

Returning a pointer is very fast, but now my class is at the mercy of callers which might write into my array. Returning a copy is safe, but so long as the callers behave themselves and don't try to write to it, is a waste of time and memory. If I could return a "copy-on-write-reference" to my array, I'd get the best of both worlds.

Any reference reached via a copy-on-write-reference would also need to be copy-on-write. If you make copy-on-write a qualifier on a variable, this could be all enforced by the compiler.

Are there any languages which do something like this?

Re:Ceylon?

[ronocdh]

It's a reference to the type of tea [wikipedia.org], as an alternative to Java—tea vs. coffee, get it?

Re:Ceylon?

[Anonymous Coward]

I *am* from Ceylon (Sri Lanka) and yes, Ceylon is to tea what Java is to coffee. Both are islands. http://en.wikipedia.org/wiki/Tea_production_in_Sri_Lanka

Re:Ceylon?

[Culture20]

Am I the only one who read, "Cylon"? Do they have a plan?

No, it's a by-your-command line language. Totally open ended.

Re:Something to watch

[julesh]

Yes, but it also means you don't have to figure out how to persist your objects to your database, how to transfer them seamlessly from one box to another in a load balanced environment, how to manage the lifetime of per-user and per-session objects, how to set up your system to locate the URLs of your web services, how to send messages from one object to another on a remote machine, how to store your resources so that they can be altered without recompilation, and many other things...

Sure, J2EE takes a while to learn. But it provides a whole load of features that would take a lot longer to write if you had to do them from scratch.