Some time ago I wrote this short article about co- and controvariance in Kotlin and how these features help the developer to write less error prone code. When I talked with some colleagues about TypeScript, I recognized that, despite some experiences I made with small pet projects, I do no know about type variance in TypeScript. Thus, I decided to take a look and was surprised. TypeScript is not that well-typed as I thought…Continue reading
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
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
We are using Kotlin and Spring Boot in one of our projects. This includes Spring Boot Jpa Repositories. We are using a CrudRepository that provides basic functionalities like save(), delete(), findById() etc. This library is written in Java, hence method signatures look like this:
Optional<T> findById(ID var1);
Using this API out of the box would force us to deal with cumbersome Java Optionals. Since we are implementing in Kotlin we would like to use Kotlin Nullables instead and as it turned out we can achieve this very easily.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.