#2337 Fantom vs Ceylon

tomcl Thu 28 Aug 2014

Ceylon is the one of the many post-Java languages using JVM infrastructure that seems closest to Fantom.

I'm flagging it here again because it is becoming more mature and while still flaky it looks like it will be fairly stable soon: the language and type system now looks solid.

It has got a poor press from the language chasers - basically saying that it is a redo of stuff that has been done before with nothing new to recommend it.

That immediately makes me think it might actually be usable.

Not perhaps quite yet. It does not seem to have any idea yet of stable libraries, and Java interop is still work in progress. I doubt it will ever have nicely sorted libraries like Fantom.

A lot of syntactic tricks are common with Fantom and clearly represent "good ways" of doing things.

The big difference is attitude towards static typing. Ceylon has strong typing with no implicit narrowing. It has a much richer type system than Fantom, based on allowing arbitrary tuple, union and intersection types, as well as generics.

Generics are always a thorny issue. Ceylon allows default type values for generics and has pretty good type inference. They claim that static error messages are always understandable.

Ceylon deals with covariance and contravariance by requiring generics in any one interface to be either covariant or contravariant but not both (so input and output parametrised types are separated). Interfaces can be combined via mixins to make more complex relationships, in which case parameters both covariant and contravariant become invariant.

Generics can have upper type bounds (in other words types that they must be narrower than) and other constraints are promised in the future.

The whole type system is simply enough for type inference by the compiler as well as type checking: that is important!

Complex types can be aliassed.

So - there is a lot of richness here (though less than in some other languages), and also a lot of complexity. Ceylon advocates claim that the complexity is regular (true) and better sorted out than in Java (true). Whether this makes it highly usable is unclear to me, because I have never programmed in Ceylon. Perhaps somone else will know...

Caveat - I may have got some stuff wrong in the above.

SlimerDude Fri 29 Aug 2014

Hi Tom, So having looked at Ceylon, in which areas do you think Fantom is lacking by comparison?

tomcl Fri 29 Aug 2014

well, if we imagined Ceylon was actually working properly...

Ceylon has generics (good anyway) and possibly defined in a way that makes them nice to use - I don't know.

Ceylon has union types and "flow typing" e.g. switching or conditional on the type of a union type infers the constituent types in the corresponding branches. This is neat and quite powerful. It works properly, so that at any place in the code types are narrowed as expected.

Ceylon has (strongly typed) tuples

On Fantom's side:

Fantom has it blocks and associated neat syntax Fantom has a nice set of well-sorted non-legacy standard libraries Fantom has built-in sequences done the way everyone would expect (Ceylon Sequences appear to have immutable length - unless I've misunderstood something - but maybe something makes up for this). Fantom has more powerful mixins Fantom has nice compile-time control over immutability

There may be some more Ceylon plusses I don't know - since I'm not very familiar with the language. What I REALLY don't know is how all those features fit together - how usable is it. What stuck me was quite a few features shared with Fantom (e.g. nullability in the type system which even used the same type notation).

rasa Fri 29 Aug 2014

@tomcl

Ceylon is the one of the many post-Java languages using JVM infrastructure that seems closest to Fantom.

Based on what you have written in your post, it seems that Ceylon is closer to Scala than to Fantom.

ahhatem Fri 29 Aug 2014

Yes, based on what you said... It indeed seems to be a less funky version of Scala that is trying to be practical and actually feasible to use. I really admire the power of the Scala type system but as some blog said: Scala is beautiful but I have work to do... I generally preferred the fantom practicality over the more powerful type system complicating my life.

SlimerDude Fri 29 Aug 2014

Scala is beautiful but I have work to do...

That's brilliant! :D

rasa Fri 29 Aug 2014

Scala is too academic. Its creator holds PhD in computer science and works in some institute in CH so Scala looks more like a research project than something intended for a daily usage. Ceylon is following its path but with a different syntax. Rich type system need not to be an advantage. Go on and google what mess can be done with just a bit of incautious using of Scala implicits.

tomcl Fri 29 Aug 2014

Obviously Ceylon has a richer type system, and Scala has a VERY rich type system.

But Ceylon is not academic, its type system is about as rich as that of Java, but much more regular.

The design aims are different, Ceylon, like Fantom, wants to be a usable language. Scala wants to be a language with a whole load of exciting features.

Ceylon does a lot with a richer but very regular, and so pretty simple type system. There is a trade off between usability and complexity. If you can make your type system simpler and more intuitive then the balance switches more towards a richer type system.

Whether Ceylon has done this I am very unclear. But that is what it aims to do, and it is also manifestly what Scala has not done. Scala has a whole load of functional programming concepts that must be understood just to use the standard libraries. That makes it a very steep learning curve for most programmers. Ceylon is not in that territory at all.

But whether it is actually usable - that is a much more complicated thing and I don't know the answer.

One area where Ceylon beats Fantom is it has a capable well-sorted IDE based on Eclipse shipped as part of the language and under active development. Good tools matter. Fantom's F4 is a bit old and definitely not being developed.

Login or Signup to reply.