To evaluate the impact of memory management in Rust, I implemented a short benchmark in Rust and Kotlin. You can find all the details here and here. Measurements showed that Rust is roughly a factor of 10 faster than Kotlin, most probably caused by better handling of memory garbage. Being a big fan of Haskell, I was curious to see how the grand old lady of functional programming would compete against these two. So, I implemented the benchmark, did some measurements, and was surprised.Continue reading
In this previous article I implemented a small, enterprisy benchmark to compare the concept of garbage collection used by Kotlin/JVM with the concept of Rust, which claims to not have any garbage collector at all. My conclusion was, that for a moderate increase in the complexity of the programming language the benchmark in Rust performed roughly 3 times faster than using Kotlin on the JVM. A colleague of mine, who uses Rust for some time now, looked at the code and gave me some hints for further speed improvements.Continue reading
Rust is getting more and more popular. Thus, a group of colleagues, including myself, evaluated it for half a day to build up our own opinion, if Rust is of strategic interest for us or not. We did some coding following the standard introduction book, looked at some frameworks, and watched the presentation “Considering Rust”. The general conclusion was more or less in the line of: yeah, a nice new programming language, but without a full-grown ecosystem and without any garbage collection, it will be too cumbersome and unproductive for us in our projects. My gut feeling did not agree with the assessment regarding garbage collection. Thus, I did some more digging and testing and came up with my current conclusion: Rust does indeed garbage collection, but in a very clever way.Continue reading
Covariance and contravariance are properties of type systems of programming languages. They can be pretty intimidating words for a software developer who just wants to implement user requirements. In this article I approach the meaning of these two properties in Kotlin from a domain level perspective. It was part of an internal small workshop on Kotlin.Continue reading
This article is a follow-up to this previous article about bounded loops. Bounded loops are cool because they always terminate and usually it is pretty easy to estimate the computational time. But as every computer scientist, who had to understand the halting problem, knows, there is a big class of algorithms which are harder. These are known as the class of μ-recursive functions. Here, unbounded loops exists which can run forever. I will introduce how IMHO unbounded loops can be implemented in Kotlin in a functional way. And, of course, I could not resist and did some measurements…Continue reading
Loops are a basic paradigm in imperative programming languages. In functional languages you also need to loop, but you do it differently. Here, I present how I prefer to implement loops in a functional style using Kotlin. To check, if this is a good idea at all, I do some benchmarks against imperative variants and good old Haskell.Continue reading
Sodium is an implementation of Functional Reactive programming (FRP) with some nice features. One of these is the support of transactions in the GUI layer. I had quite some discussions with my colleagues on what this actually means and if such a transaction concept is useful or not. In this article I sum up my current insights and opinions about transactions in Sodium.
Functional reactive programming (FRP) is a variant of reactive programming for the development of user interfaces based on the functional paradigm and a strict set of basic operators. In contrast to reactive frameworks, such as RxJs, using FRP enables a developer to define a pure area in her code in which some error classes, typical for event-based architectures, do not occur. Sodium is an FRP-framework, which is independent of a specific GUI-framwork and supports several different programming languages. Here, we describe how to use Sodium together with Angular.
In No more Ifs I wrote a little bit about the new Optional class in Java 8. It enables the developer to work with optional values without a complex nested structure of if-then-else expressions. A colleague of mine, being a big fan of Kotlin, dropped a hint that using Kotlin, it would be much easier. He could even prove it. 🙂