I think perhaps the least ergonomic syntactic feature of Ceylon has been the syntax for attribute initialization. I never ever managed to get comfortable writing the following:

//old syntax!
class Person(String name, Integer age=0) {
    shared String name = name;
    shared variable Integer age:=age;
}

Now, I hate the verbosity of C++/Java-style constructors, but one thing they definitely have going for them is that they give you distinct namespaces for class members and constructor parameters. Ceylon's more compact syntax doesn't give you that, so we had to come up with the ad hoc rule that parameter names hide attribute names, since we didn't want people to be forced to always name parameters like initialName, initialAge, etc.

Worse, this ad hoc rule results in some fairly pathological stuff. Consider:

//old syntax!
class Person(String name, Integer age=0) {
    shared String name = name;
    shared variable Integer age:=age;
    this.age:=1;
    print(age); //would print 0 
}

So we were forced to add some extra smelly rules to let the compiler detect and prevent things like this.

Well, this solution has finally worn out its welcome. We've decided to take a different approach in M3. (Indeed, I just finished updating the language spec and type checker.)

Now, the above can be written like this:

class Person(name, age=0) {
    shared String name;
    shared variable Integer age;
}

That is, a parameter declaration can now simply be a reference to an attribute, in which case its type is inferred from the type of the attribute. The parameter itself is never addressable in the body of the class, but it's argument is automatically used to initialize the attribute. That is, there's only one unambiguous thing called age:

class Person(name, age=0) {
    shared String name;
    shared variable Integer age;
    age:=1;
    print(age); //prints 1 
}

The really nice thing about this solution is that it gives us an extremely terse and well-organized syntax for "data holder" classes.

class Address(street, city, state, zip, country) {

    doc "the street, street number, 
         and unit number"
    shared String street;

    doc "the city or municipality"
    shared String city;

    doc "the state"
    shared String state;

    doc "the zip or post code"
    shared String zip;

    doc "the country code"
    shared String country;

}

I think it would be hard to come up with a more readable syntax than this!

UPDATE: It's interesting to compare this solution to the syntax used by Dart, which is along the same lines. I swear I didn't copy!

Last week we did a presentation at Devoxx France in Paris, with Emmanuel, and I had the opportunity to talk about Ceylon in an interview where we discuss Ceylon for almost 13 minutes.

If there's one thing the whole Ceylon team has in common it's that we're pragmatists. We have a ton of ideas of how we can make the programmer's life better with Ceylon, and we try to do it whenever we can. In fact, we have so many ideas that it's hard to bring them all to fruition. With people such as Gavin and I in the team, being very involved in Web Frameworks, I can tell you that among the many things we want to do with Ceylon, the only thing holding us back from writing an excellent Web Framework for Ceylon (or adapting one) is that we simply have more urgent things to fix right now.

Why we needed a new module repository

One of those urgent things to fix, we quickly realised, was to have a better, leaner, nicer, friendlier module repository for Ceylon modules. You probably know by now that all the Ceylon tools can already talk to module repositories, local or remote. By talk I mean, use and publish to.

We added support for WebDAV from the start, and then we tried it and found that it was actually hard for people to set up WebDAV on their server to set up their own repo. Because that's the thing with open-source: we're not trying to solve the repo problem just for us, but also for all our users. We want them to be setting up repos as easily as we do.

We went and looked at the existing module repositories like Perl's CPAN, Ruby's Gems, Maven's Nexus, or Play's modules. We liked what we saw in some of them, but what we noticed was that none of them had all the features we wanted for a great repository experience. Probably the sum of them all would be the Best Repo In The World, but truth is, it'd probably be a spaghetti monster too.

We wanted something that looks nice for consumers, with a friendly, clear and intuitive interface, but at the same time we wanted to make it just as easy for producers, with a clear path to publish modules, and at the same time a collaborative aspect, such as found in Github that we like so much.

Ceylon Herd

So we spent a couple of days banging code together and came up with the following quite impressive list of features for consumers:

• Browse repository as file system
• Browse module list
• Search for modules
• Browse module documentation
• View module information, such as dependencies, docs, source
• Links from modules to file system view and back
• Feeds to catch up with new modules, new module versions or modules published by user
• View user activity (list of published modules)

And for producers:

• Public registration
• Integrated interactive project claim (more on that later)
• Upload area: to create private staging repos where you upload your modules
• Uploaded modules are checked by our system to help you:
  • Module paths
  • Module ownership
  • Duplicate module detection
  • SHA1 Signatures verification
  • API docs presence verification
  • Source code presence verification
  • Dependencies check
  • Many other checks
• You can upload multiple modules at once
• Upload using the Ceylon tools or the website, individual artifacts or with a zipped repo
• Publish your modules once all verifications pass
• Edit your module information
• Grant publishing permissions to your colleagues
• Transfer module ownership

You're not dreaming, we did all of this, and a lot more under the hood as well as in the UI, to make sure newcomers are not overwhelmed or abandoned, to make sure everyone feels right at home in Ceylon Herd, our open-source Ceylon module repository.

You heard that right: today we unveal our official module repository, called Ceylon Herd, which is where we are (we as in me, you, everyone) going to publish our Ceylon modules for all to use. And because we're open-source guys, and we don't want to lock people into a fenced-wall service, we're making Ceylon Herd available as Free Software, so that everyone can not only contribute to make it better, but use it privately or publicly.

Our version of Ceylon Herd, running at modules.ceylon-lang.org, will be the official place to get official Ceylon modules, as well as the central place to get third-party modules, as long as they are open-source. We're still working out the details of the hosting policy, so we've disabled registration for now, which means that for you guys it is purely read-only until we open it up completely, but rest assured that will happen as soon as we can, so you can start sharing too.

Meanwhile you can start consuming the few modules we put there to get you started.

Who can publish what?

Because we plan to use Ceylon Herd as the official Ceylon module repository, we need to make sure that the modules published there are legit and functional. If John Doe can come in and start publishing modules he doesn't own, or participate in, or represent, then that's just bad for our repository. John Doe is free to use another Ceylon Herd instance, but we're going to be careful who we let publish in modules.ceylon-lang.org.

So our solution is called project claims: when you have registered on Ceylon Herd, you can claim a project (essentially a module name), and you explain its license, point to its home page, who you are and why we need it in Ceylon Herd. We're immediately notified and start checking up on the project, verify that you are who you say you are, and that you should indeed be allowed to publish on behalf of that project.

This verification is an interactive process, we may ask you questions, via comments on the claim, which you get notified about and can answer. As soon as we've made up our mind, we'll either confirm your claim, or reject it. If it is rejected, don't be afraid to re-claim it if you feel we were wrong, we can discuss it again, especially if you have new and good evidence. We're only trying to help authenticate module publishers, not control what goes in or not (though it has to be open-source).

Once your claim is verified, you are free to publish as many versions of your module as you want, as well as delegate publishing of that module to other Ceylon Herd users (your colleagues, project buddies, spouse or kids for the luckier). At any moment you can transfer project ownership to another Ceylon Herd user.

If you think this is not good enough, please let us know.

OK, enough with the prep talk, how do I get started?

Ceylon Herd is available here, we can help you get started, and you can even download its source code to run it where you want and improve it. Use, follow, share, contribute, have fun!

Stéphane and I have been interviewed in Les Cast Codeurs Podcast. We casually discuss Ceylon for a little more than an hour. We touched on the philosophy of the language, dived in some of the features and discussed the future and the community.

The only catch is that we talk in French. Now you have to learn two new languages :)

You can listen to the Ceylon episode directly or see it in iTunes.

Today, we're proud to announce the release of Ceylon M2 "Minitel". This is the second official release of the Ceylon command line compiler, documentation compiler, language module, and runtime, and a major step down the roadmap toward Ceylon 1.0, with most of the Java interoperability fully specified and implemented.

You can get it here:

http://ceylon-lang.org/download

We plan a compatible M2 release of Ceylon IDE later this week.

Language features

In terms of the language itself, M2 has essentially all the features of Java except enumerated types, user-defined annotations, and reflection. It even incorporates a number of improvements over Java, including:

• JVM-level primitive types are ordinary classes in Ceylon
• type inference and type argument inference based on analysis of principal types
• streamlined class definitions via elimination of getters, setters, and constructors
• optional parameters with default values
• named arguments and the "object builder" syntax
• intersection types, union types, and the bottom type
• static typing of the null value and empty sequences
• declaration-site covariance and contravariance instead of wildcard types
• more elegant syntax for type constraints
• top-level function and value declarations instead of static members
• nested functions
• richer set of operators
• more elegant syntax for annotations
• immutability by default
• first-class and higher-order functions except anonymous functions
• method and attribute specifiers
• algebraic types, enumerated types, and switch/case

Support for the following language features is not yet available:

• anonymous functions
• multiple parameter lists
• comprehensions
• mixin inheritance
• member class refinement
• reified generics
• user-defined annotations and the type safe metamodel

This page provides a quick introduction to the language. The draft language specification is the complete definition.

Java interoperability

There were many improvements to Java interoperability in this release, which makes it very easy to call Java from Ceylon.

Most of the interoperability issues with Java have been fixed, and there are very few remaining issues that we will fix for the next release, though they only concern corner-cases that we don't expect users to meet.

Performance

We spent a lot of time improving performance for this release, in particular arithmetic operator performance, but we still have a lot of areas we expect to improve for the next release, such as the speed of interoperability with Java arrays and improvements on boxing.

Modularity and runtime

Ceylon modules may be executed on any standard Java 6 compatible JVM. The toolset and runtime for Ceylon is based around .car module archives and module repositories. The runtime supports a modular, peer-to-peer class loading architecture, with full support for module versioning and multiple repositories.

This release of Ceylon includes support for local and remote module repositories, using the local file system, HTTP or WebDAV. In order to make it easy to use Java libraries from Ceylon you can even use Maven repositories.

Support for the shared community repository modules.ceylon-lang.org will be available in the next release.

Chapter 7 of the language specification contains much more information about the Ceylon module system and command line tools.

SDK

At this time, the only module available is the language module ceylon.language, included in the distribution.

Source code

The source code for Ceylon, its specification, and its website, is freely available from GitHub:

https://github.com/ceylon

Issues

Bugs and suggestions may be reported in GitHub's issue tracker.

Community

The Ceylon community site includes documentation, the current draft of the language specification, the roadmap and information about getting involved.

http://ceylon-lang.org

Acknowledgement

We're deeply indebted to the community volunteers who contributed a substantial part of the current Ceylon codebase, working in their own spare time. The following people have contributed to this release:

Gavin King, Stéphane Épardaud, Tako Schotanus, Emmanuel Bernard, Tom Bentley, Aleš Justin, David Festal, Flavio Oliveri, Max Rydahl Andersen, Mladen Turk, James Cobb, Tomáš Hradec, Michael Brackx, Ross Tate, Ivo Kasiuk, Enrique Zamudio, Julien Ponge, Julien Viet, Pete Muir, Nicolas Leroux.