using LibGDX with Kotlin, a Kotlin novice perspective

By | May 27, 2017

Momentum has been gathering behind Kotlin for some time now, and like many programmers from time to time you just have to investigate a new language.  Usually in a new language what you are really testing out is the infrastructure around the language, but in common with the other JVM languages you have a fantastic wealth of libraries and tools to draw from which you are already familiar with.

I have to say that the first hour or so was extremely frustrating, arguing with an IDE trying to get any traction, fortunately the creators of Kotlin have made a set of Ant tasks for working with Kotlin. Inside literally five minutes I had Kotlin compiling with my project laid out how I wanted it.  YMMV while I personally think IDE’s are usually more trouble and work than they are worth, you may well love them.

I did make use of Ideas just to convert a very simple GDX example (rendering a single texture) just so I had a known working starting point.  Alas there seems to be no syntax highlighting for Geany (which is slightly more IDE that I like) so I’m currently looking at Atom, an editor that is reasonably lightweight, I did look at the Kotlin lint plugin but that seemed to slow things down and I couldn’t figure out how to show it where the jars were I was importing so I soon disabled that particular plugin…

Kotlin has a nice feature that source doesn’t need to be in any particular file hierarchy regardless of what package they are in, it was also easy using the Ant task to specify multiple source paths, this means you could for example have different platform stubs in separate directories kept apart ready for different build tasks.

For a Java user, the bit of “muscle memory” that will keep tripping you up is variable type definitions, not a great deal as I used to love Pascal before Delphi went all *shudder* ActiveX, but it has to be said Kotlin seems to be a language you can get to grips with in very rapid order

Loops especially FOR are handled really nicely …

    for (i in 1..20) {

is simple and really very intuitive, in a similar way stripped of random ascii soup you get in some languages

    for (p in pobs) {

is equally intuitive – although for me you could take out the brackets but then you’d probably have to make the curly braces mandatory, so swings and roundabouts!

There does also seem to be some canny rules in place that I suspect make optimisations easier for the compiler, the need for lateinit for example hints at this, of course this is all before looking at the wealth of things like data objects, and delegation, all things that haven’t been needed for a trivial initial investigation…

On the whole the Kotlin compiler seems much less fussy (I’ll be charitable and not mention it can’t infer that a number could be a floating point literal, oops I just did!) and despite being less verbose, this doesn’t seem to detract from its inherent readability.

Despite only using a very small subset of Kotlins features (and very probably not idiomatic) making use of a comprehensive library such as libGDX was both easy and quite rapid, with any obscure compiler messages being reasonably easy to figure out a cure for.

All in all if you’re not over keen on the direction that Java is lurching in and you want a language that offers ease of use and powerful features, at least at first glance it looks like Kotlin is well worth a closer look

For what its worth you can find the source code for my initial experimentations here (see video above)



Leave a Reply

Your email address will not be published. Required fields are marked *