I’ve spent the last few days somewhat diligently playing around with Rust. That’s mostly been studiously reading The Rust Language Book and doing some of the examples. I’m quickly tiring of that and will have to move on to koans, tutorials, or just some projects. However each day I’m learning a bit more about rust. There is a little more insight each day, mostly positive, but one area I am having some concerns is the area of error handling. Specifically I’m concerned about their lack of any traditional exception handling and in its place only returning error objects or panicking (crashing) the whole program.
As I tweeted about over the weekend, I’m going to be starting a month of deep diving into Rust for the month of May. I’m not trying to be a complete convert. I have work to do after all. However I really want to explore this new lower level language as opposed to my day to day work in managed and interpreted languages. I’m going to try to spend an hour or so each day working through tutorials and maybe trying to build my first real application with it. I’m starting with the Rust website seems to have some great resources like a language guide book and tutorials. I’ll go on from there. Today however was just getting the system setup and working through my first hello world tutorials. So far it’s been a mostly positive experience.
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.