Software engineer with a focus on game development and scalable backend development
Ever since I started making use of Docker I have always been at a turmoil on whether a JVM language was the best solution for the job. You see JVM has a great level of support with loads of libraries a number of different languages and great performance, however this comes at a cost of a large runtime environment and memory requirements (not to mention warm up times). On the other hand there are languages like Go that include everything you need to build a webapp in the standard library, produce a small single binary and dont have large memory footprint or startup times. Go felt like a much leaner language better prepared for this era of microservices and small docker containers, that is until GraalVM came about.
One of the things I like most about languages like GoLang is the fact you can create a small executable that holds all the files needed for a server, or any other application. Kotlin, and any other JVM based languages, however always seem to be rather bloated, Kotlin and Spring have often been over 100mb, and even Scala and Play Framework are of a similar size.
Kotlin is a programming language developed by Jetbrains in 2011 as a JVM alternative to Java, it gained popularity amongst Android developers and in 2017 Google started officially supporting it as a first class language on Android. Until now I had only used it on Android but with the release of Spring 2.0, and the official support of Kotlin, I thought now would be a great time to try it out!
In 2014 Double Fine released a game by the name of Hack ’n’ Slash, the premise being that you could access the code running the game and modify it to change how the game works, it was a really cool premise though maybe not that interestingly implemented. The way it worked was by using a scripting language to run the logic of the game actors and thus allowing you to modify their code.
I have been building a couple of prototypes recently and came accross the need to use native code in one of them, specifically on the backend. After debating which tech I should try out for this, I decided to give it a test and figure out if the performance differences could sway my vote between my usual go-to languages, Scala and GoLang.