News for hackers. Stuff that matters.

Bienlein

Mail to bkase at highlig.ht bounced back. Are you sure the mail address is correct?
"Why not start with a mixed Java/Kotlin project?" Think that's a good idea. If you are missing AST transformations you can add Groovy to the game. All three languages in IntelliJ work really fine together. In eclipse you might have to rebuild the entire project when doing mixed language programming. I learned this were a problem with ecliupse, though.
I started looking into Kotlin already when it was M2. Always liked it a lot, because every feature has a reason to exist. Nothing is added without careful thought whether it is needed at all or could be solved in the library anyway. Scala would have been a much more consistent language if the Scala people had progressed in this way as well and Scala code would also be much easier to read.

Kotlin seems to have a killer feature which is Android development, which is of course good. But what about internal enterprise development? It makes me think whether Kotlin has enough added value to make people change from a safe haven like Java8 to Kotlin. Sure, much better build times and less problems with code readability when using Akka, Play, Spark with Kotlin instead of Scala. Also Kotlin offers much more power in exploiting the features of those tools compared to Java. But how many people use Akka or Spark? Nevertheless, I wish Kotlin all the best. I will always greatly prefer it over Java or Scala.

"Kotlin interfaces are essentially the same as Java interfaces." Interfaces in Kotlin offer functionality beyond interfaces in Java. In Java interfaces can only have public methods. In Kotlin interfaces can also have (abstract) variables. Both, methods and vars, in Kotlin interfaces can be public and also protected. You need this if you don't want to break the encapsulation of your classes that implement an interface.
Kotlin is build with interoperability with Java in mind from the beginning. This is not the case in Ceylon. In fact some base types (Int, Long) in Ceylon don't match the corresponding Java type. Kotlin has extension methods which Ceylon has not. Ceylon has reified types, which Kotlin has not. Ceylon went 1.0 in November 2013. So far Ceylon seems not have caught any traction, which is unfortunate as it also is a language well-made in many ways. Kotlin has at least Android development to create some initial traction.
>> No reason to bake it into the language

Go-style channels and goroutines are built on green threads which Go/Erlang has, but the JVM does not have. One way to work around this is to use fibers and continuations which is what Quasar is doing.