Hacker News Reader

Comment by hrjet | Hacker News Reader

The features look very inviting. When choosing a language for a new project, I am torn between Kotlin, Scala, and now, Ceylon.

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.

View on HN

(Scala tech lead at Typesafe here)

> 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).

Thanks for your response. I appreciate all the work going into the Scala ecosystem.

> 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.

Thanks for clarifying. I understand your concern. The Scala side of our commercial offering aims to alleviate those worries. Please get in touch if you'd like more details on that.

> 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.

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

Sorry to hear that. It's a lot of work and the Scala team at Typesafe is pretty small. We welcome all the help we can get, but we're focussed on solving exactly these issues. If you'd like to get certain bugs prioritized -- we offer dev support.

Kotlin and Ceylon are very similar feature-wise, but their ambitions and tradeoffs are completely opposite. Ceylon tries to remake and replace the JDK with new libraries (i.e. modernize everything) while Kotlin has Java interoperability as one of its top priorities, at the expense of some compromises in the language/libraries.

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)?

FTR, Ceylon's Java interop is _excellent_, especially in this latest release, and Ceylon makes it absurdly easy to use the Java SDK directly from Ceylon.

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, sure, we have the language module, and `ceylon.collection`, `ceylon.locale`, etc, which abstract away from the JVM, but that's necessary, since Ceylon also runs on JavaScript VMs. That _doesn't_ mean you can't easily use `java.lang`, `java.util`, and the rest of the Java SDK if you need it.

So it's not quite right to think that Ceylon is lacking in this area. It's actually a strong point of the language.

I don't think it's lacking (only lacking wrt Kotlin), but that it isn't one of the top two concerns of the language: i.e. it's possible and maybe kind of easy, but certainly not seamless. 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. Kotlin also compiles to JavaScript, but it's much more a "hosted" language than one that tries to abstract away the host's native APIs.

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.

>> but that it isn't one of the top two concerns of the language: i.e. it's possible and maybe kind of easy, but certainly not seamless. <<

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.

>> Kotlin also compiles to JavaScript, but it's much more a "hosted" language than one that tries to abstract away the host's native APIs. <<

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! * Second, because even if you _could_ clearly discern the boundaries of java.base, there are plenty bits of it which _simply can't be implemented in JavaScript_. Seriously, there are a bunch of operations that I would love to add to ceylon.language, but can't, because they are simply unimplementable in JS. * Third, because _the basic types of the Java language_ are only meaningful on the JVM! You have types like long, and double whose semantics are 64-bit precision, and int and float whose semantics are 32-bit precision. But on a JavaScript VM, all numbers have 53 bits of precision! So the basic semantics of the type simply can't be satisfied. On the Dart VM, the situation is a lot better, since at least the two numeric types they have are both 64 bit, but that still leaves int, short, float as basically completely meaningless types.

So if you're truly serious about JavaScript VMs or the Dart VM or whatever as a real target platform for your language, you need to design your language and language module for that.

>> 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.

> 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.

OK, sure, thanks for your comments :-)

This was very interesting to read.

> So if you're truly serious about JavaScript VMs or the Dart VM or whatever as a real target platform for your language, you need to design your language and language module for that.

Would it be fair to say that Ceylon's design is heavily guided by the needs and constraints of Javascript in addition to Java interoperability? I am concerned that those of us who only care about pure JVM projects will be carrying the extra burden imposed by Javascript.

I would say that Ceylon is heavily guided by the constraints of wanting to always do The Right And Elegant Thing, and not unduly compromise on that in light of the nature of the underlying VM. _Which_ VM doesn't quite enter into that question.

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.

So to clarify: ceylon.language and ceylon.collection are designed the way they are because they're like way better and cleaner than java.lang and java.util. Not because they represent a "compromise" with JavaScript.

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.

As a further clarification, when I said: "there are a bunch of operations that I would love to add to ceylon.language, but can't, because they are simply unimplementable in JS", I don't mean that those operations aren't available. Just that they're exiled to a different module.

As a further sort of clarification: we're Java developers, not JavaScript guys. We recognize the importance of the JavaScript VM. But Java is where our hearts are at ;-)

Is there an introduction to web app development in Ceylon? I'm curious how it compares to React / Angular / GWT / Dart.

Oh yeah, we definitely need to write this now that vert.x's Ceylon integration just released it's 1.0 version!

vert.x looks server-side? I'm more interested in running in the browser. (Compile to static files containing JavaScript.)

Yes, I understand. What I mean is a whole tutorial that shows a ceylon client in the browser calling a ceylon sever running on vert.x.

I didn't use Kotlin in production, but non-nullable types are a blessing and a curse. Non-nullable types are long-overdue. However, most Java libraries do not have non-nullable annotations. So, even if e.g. method arguments should never be null, they are presented as nullable.

You can use external annotations[1], 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[2], 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.

[1] http://blog.jetbrains.com/kotlin/using-external-annotations/ [2] http://blog.jetbrains.com/kotlin/2013/03/kannotator-0-1-is-o...

Well it all depends how you handle `null` at the boundary between the two languages. In Ceylon, we let you write either:

    String str = javaObject.javaMethod();

or:

    String? str = javaObject.javaMethod();

In the first case, we insert a runtime type check that throws an `AssertionError` if `javaMethod()` returns `null`. In the second case we don't.

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.

The first case would be a compile time error in Kotlin. How is a runtime AssertionError better than a runtime NullPointerException?

> The first case would be a compile time error in Kotlin

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: http://blog.jetbrains.com/kotlin/2014/10/making-platform-int...

Well it is somewhat better because it occurs immediately when the null value passes from Java code with unsafe null into Ceylon code with safe nulls.

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.

The next release of Kotlin has a change to the type system to make this a lot less painful, apparently. I'm waiting for it before proceeding with Kotlin.

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.

Reply on news.ycombinator.com