This pro-Swift article came across my RSS feed recently and while I don’t want to do a direct comparison of Swift versus Kotlin since I haven’t done Swift coding I did think it was interesting to point out similar points of efficiency in their simple example built as a product of the Kotlin language compared to others like Java, the language they picked on too.
As I wrote about here yesterday I am taking my exploration of Kotlin to the next level by looking at performance metrics using the Computer Language Benchmark Game. As of right now I’ve completed my first two steps: got the benchmark building/running Kotlin code, and doing a straight port of the suite (follow along at the Gitlab project). This was really 90% IntelliJ auto-converting followed by me fixing compiling errors (and submitting a nasty conversion bug that came up from one test back to JetBrains). So now onto the results! Well, actually not so fast on that one…
I may be enamored of my new programming toy, Kotlin, but I’m not one to go blindly into something like this. While there is a lot to love about the language I was curious how fast it was compared to Java. It’s all running in the same JVM but as I know from Scala, another JVM language, there can be dramatic performance differences. Benchmarking is the usual, and probably clichéd, way of addressing that. The Computer Language Benchmarks Game website is as good a place as any to start. Unfortunately no one has bothered making Kotlin language tests yet. Undaunted I saw this as an opportunity to contribute back as well as get a little extra Kotlin coding in. So, I’ve started a fork to develop and contribute back Kotlin versions. You can follow along and/or contribute to the port at my Gitlab project.
My approach to this endeavor is as follows:
- Update the project drivers and initialization files to get Kotlin running
- Do a straight translation port of the latest version of each of the Java benchmarks
- Compare the performance of the straight-port versions Java
- Create tweaked versions of Kotlin versions to further optimize
- Compare the performance of the tweaked versions to Java
I’ve already completed the first bullet, and the develop branch of my repo. I think the initial two bullets will go relatively quickly. Tweaking and optimizations will be another matter.
PS a big thanks to Sebastian Thiel for setting up a project/repo that is constantly mirroring the Benchmark Games’ CVS repository. It is an indispensable plus to be able to have the latest and greatest automatically (also thanks to Gitlab’s integration capabilities) as development moves forward.
Back in November I started trying to mess around with .NET again, with the twist of I refused to become Windows bound to do it. After some time experimenting holidays got in the way, then work got in the way, and as usual life gets in the way of hobbies. Today I needed to work out some standard C# code samples for interacting with REST services I had written in Java. I could have spent two hours installing Visual Studio in the virgin Windows 10 VM on my laptop, or I could fire up a new Linux VM and give cross platform .NET another try.
I am very early in the Linux .NET development experiment. I am pretty busy with work and life so that I don’t have a ton of time to play around with these things. Having come from a background where most of my recent development (last several years) has been technologies other than .NET I have a double hurdle to clear: getting used to .NET and getting used to doing .NET on Linux. Therein lies the rub.
I may have cut my teeth on non-Microsoft systems but the better part of my career was spent building most of my software with and for Visual Studio. It was only in the last few years that the landscape changed and my work has been dominated by Linux, Java, and generally non-Microsoft systems. I’ve thoroughly enjoyed the explosion of open source software and the ability to contribute to and use it. I’ve also enjoyed being able to extricate myself from Windows. But with Microsoft’s recent foray into open source and with the increasing stagnation and calamities in the Java community I’ve decided to give the .NET stack a while again, but with a twist.