Scala had its time, and I was a frequent user, but now I am not sure where it is going. It certainly helped bring functional programming into my vocabulary, and into a lot of other developers' too. But I get the impression that it tries to appease to many different notions, and lacks a core guiding principle. (In a more positive light: it is more democratic).
Kotlin and Ceylon seem to be more streamlined, and centered on a few core principles. Ofcourse, I haven't actually coded in them, so they might be presently appearing rosier than they are. Especially after trying Xtend, I realized that there are many corner-case (but important) scenarios that burn you when you actually try a non-trivial project in these new languages.
Would love to hear experiences from those who are using Kotlin, Ceylon or Xtend in production.
> Scala had its time, and I was a frequent user, but now I am not sure where it is going. It certainly helped bring functional programming into my vocabulary, and into a lot of other developers' too. But I get the impression that it tries to appease to many different notions, and lacks a core guiding principle. (In a more positive light: it is more democratic).
You sure piqued my interest there! Could you elaborate?
Why do you say you don't know where Scala is going? Our roadmap is intended to be pretty simple: stability + full Java 8 support. Our guiding principle is to make sure your investment in your Scala codebase is safe in the long term, which entails a tricky balance between stability and getting rid of stuff that turned out not to work that well (we do this slowly, though still much faster than Java).
I'm glad you feel we're more democratic. We certainly try to be transparent in what we decide to work on as a company (which implies the community is welcome to pick up our slack, and we do try to help out where we can -- see e.g., the Typelevel fork).
> Why do you say you don't know where Scala is going?
Apologies for that wording. A more elaborate wording would be: I don't know where Scala as a whole (the community + language) will be heading and that is in huge part because of I not having the resources to follow the developments. I sometimes lurk in the internal discussions list and catch up with conversations, some of which tend to be controversial, but I am glad they happen in the open. (Top of mind: CPS plugin related discussions)
I still use Scala whenever I can, but when it comes to performance (cpu limited), I fall back to Java. (I am aware of the compiler plugins of yore and the macros of now that help speed things, and the tree shakers, but they are third-party / require different workflows, and hence I don't feel inclined to use them for certain projects).
It is mostly in this space that I am exploring alternatives. Kotlin and Ceylon seem to be more streamlined (conceptually, and hopefully at run-time), but as I haven't actually used them, I am not sure what deficiencies to expect.
Edit: Removed a sidenote. Would have been a distraction.
Given that I hit serious, show-stopping Scala compiler bugs at least once every few weeks -- bugs that always have already been filed and simply haven't been fixed -- and that Scala binary compatibility across major releases is still a pipe dream, and that massive language warts don't seem to be going anywhere ...
... I'm not really seeing how that roadmap and reality come together. I've got a smidgeon of hope for the two Scala forks, but I know that's a long shot.
-- fulltime scala user
I think that Kotlin takes the more pragmatic approach, and introduces much less risk to the project (I use Kotlin and Java classes in the same package, and it's very easy to replace one with the other). So while neither is as mature as Scala (I really don't like Scala but I won't get into that again), Kotlin is as close to risk-free as possible, while Ceylon is more ambitious. It comes down to your personal preference: are you an idealist or a pragmatist (said half jokingly)?
Indeed, the Ceylon compiler's Java backend is actually built on Open JDK - that is, it is essentially `javac` itself that generates the bytecode - so we know that the bytecode we generate is extremely close to what Java itself would generate, including full information about generic types that the Java compiler can understand.
So it's not quite right to think that Ceylon is lacking in this area. It's actually a strong point of the language.
You're doing great work with Ceylon, I like the type system, and I certainly wouldn't mind a "new JDK" that's as good as the current one minus all the warts that have accumulated over the years, but adopting Ceylon today, I think, is a much bigger risk than adopting Kotlin.
Well it's certainly _a_ top concern, and one we've invested a huge amount of development effort in! Indeed, we could have delivered Ceylon literally a year or more earlier if we had not decided to jump through so many hoops to make the Ceylon compiler generate generic type info that the Java compiler understands.
>> This might be (and I don't know enough about it, so this is conjecture) one of the reasons why writing Kotlin on Android is pretty simple, while Ceylon not so much. <<
Well, no, I don't think so. It's not that _Ceylon_ doesn't have great Java interop; it's that _Android_ is not quite fully Java compatible! I can't just say to you: "oh, it's Java, so it will work". No; we can't depend on that.
But really the only reason that we don't have a welldefined story for running Ceylon on Android is simply that we haven't had time (yet) to invest the effort into trying it out and finding any sources of discomfort and fixing them and making it work, whereas perhaps the Kotlin team has done that already.
But we _will_ work on this, and I'm certain that we'll be able to make it work.
Well the problem is that if you don't abstract away from the VM with your language module, and instead try to treat java.lang+java.util+whatever as providing your basic language types, or as dependencies of the module that provides your basic language types, then you simply _don't have a well-defined foundation for cross-platform development_.
* First, because the Java SDK itself is not modular, and the "boundaries" of what bit of the SDK is Java's "language module" is ill-defined. This is a real concrete problem for people who develop on GWT, so it's not some theoretical concern that I'm inventing!
>> adopting Ceylon today, I think, is a much bigger risk than adopting Kotlin. <<
I'm not arguing, nor I would I ever argue, that there are no sources of discomfort that arise from having a cross-platform language module. There surely are, but they're minor, they're well-defined, and they're essentially very easy to work with. We've already written quite a lot of code that makes heavy use of Java libraries, and we've been identifying sources of discomfort and fixing them when/where necessary as we go along.
Nor would I suggest that there were no bugs/limitations in Ceylon 1.0. There were! And we fixed the ones we found. And surely we'll find a couple more in Ceylon 1.1. But we remain deeply committed to fixing such bugs.
Given that, calling it a "risk" is, I think, a bit of an unfair characterization. A "source of occasional discomfort", would be fairer.
What I meant by "risk" wasn't technical difficulties, but a contingency plan if the young language doesn't take off. Even though Kotlin and Ceylon are very similar, it's easier to change back to Java from Kotlin than it is from Ceylon (and I'd argue that it's easier to gradually introduce Kotlin into a project -- a class here and a class there -- than Ceylon).
Still, both Ceylon and Kotlin are a nice, gradual evolution of "blue-collar" programming languages, and I hope one or both gain widespread adoption.
We're not crazy about this; of course compromises are necessary; hell, we just added use-site variance to the language purely to make Java interop better.
Likewise, the main reason that Ceylon only has 3 numeric types (Integer,Float, and Byte) is because that seems to me the Right Thing from the point of view of the goals of the Ceylon type system. It just so happens that this is also the right thing if you want cross-platform execution.
Hope that answers the question.
You can use external annotations, but they are a lot of work. Also, you need to ensure that anyone using your code has the same external annotations, and that they are still correct when a library is updated.
There is also a tool that can automatically infer the annotations, but last time I tried it was definitely not perfect.
Of course, it's possible to live with this, but like Scala a lot particularities of the underlying platform leak into the stronger typing and abstractions that these languages provide.
String str = javaObject.javaMethod();
String? str = javaObject.javaMethod();
That is to say, the Ceylon compiler recognizes that it's dealing with a Java library where information about null is simply missing from the method signature and adjusts accordingly.
Having the compiler produce an actual error in this case seems wrong and excessive, since the compiler does _not_ know better than you whether javaMethod() can return null. It simply doesn't have that information when calling Java code.
FYI, Kotlin will have the same behavior as Ceylon in the future, i.e. it's going to be a runtime error in the first case:
As to kotlin vs ceylon, no real strong preference either way, they both seem strong. I'm planning on going with Kotlin longer term because I am already an IntelliJ user and because it has a Java-to-Kotlin converter.
Do note from the http://groovy.codehaus.org/Groovy+2.3+release+notes that the "JDK 8 and its interface default methods introduced some incompatibilities with a few methods of the Groovy Development Kit, so we had to adapt to the situation, introducing minor breaking changes for the affected methods and their outcome."
Also note the "Breaking changes" list hidden at the bottom of that page, which probably only lists some of them.
The syntax looks way easier to me (I'm familiar with ruby) than Rust, but are there any use cases where Ceylon targets over Rust and vice-versa?
EDIT: NM, the one is for systems programming (Rust) the other one is for high-level OOP (web-based apps, gui, etc.)