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

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