A dissatisfaction with the Kotlin compiler (seemingly you can't compile inter dependent sources on their own...) lead me to have a quick look at other JVM alternatives. Scala is a project which by now is mature and stable, its also had significant financial backing from a number of sources, which at least gives you the impression it's here to stay! I had a quick look at the Scala sbt build tool, but in common with many none KISS build systems it left me cold, fortunately the Scala cli tools are more mature and powerful so I was able to leverage Make to make an ad-hoc lightweight pseudo incremental build system... (YMMV you should probably use sbt!) The first thing I noticed was that Kotlin has obviously been quite heavily influenced by Scala, the differences however are interesting. I found it quite ironic that after using the new keyword for years in Java, a short exposure of not needing it Kotlin made me wonder why I was having to use it in Scala. A very minor thing but it is often the little differences that can be more interesting than the obvious. Porting my test code from Kotlin to Scala was a trivial exercise which was useful to point out the differences, for loops are similarly intuitive, needing less ascii soup than Java
for( i <- 1 to 20) {
for (p <- mainApp.pobs) {
You can just as easily iterate a range or a list in an easily typed and eminently readable manner.
One slight hiccup with the port was that the box2d part of libGDX has a field named type, this causes issues with the compiler as it's keyword in Scala (one I need to read into from the brief glance I've had!) however there is a simple solution without having to hack getters and setters into an existing library
bodyDef.`type` = BodyDef.BodyType.DynamicBodyThankfully the back tick operator is enough to help the compiler out (phew!) A minor irritation was the use of companion objects, even within the class you need to explicitly prefix the companion objects name.
Kotlin Scala afield = 42 mainApp.afield = 42With a library like libGDX where you override for example the applications render method, you do end up needing a number of "static" variables, needing to name the companion object every time you use a companion member does seem to add needless verbosity... Scala's object oriented approach seems to only allow you to extend from a single object until you discover traits, which look to be a powerful and much better way of dealing with the sticky mess that multiple inheritance can so easily become. On an initial impression it does seem that Scala is more Object Oriented with Kotlin leaning to functional programming, that said there are even at a quick glance a range of functional facilities in Scala Scala does indeed warrant further investigation... You can get the full source here