A lot of applications seem to either only use runtime exceptions or only use error monads like the Optional for error handling. In this blog I will try to dive a bit deeper into when to use one over the other (tldr: you probably need both)

Context with receivers is a new experimental Kotlin feature. So let’s explore this feature a bit and see what it is all about.

Let me start off with saying I love functional programming. Although.. A better way of saying it would be I love what functional programming brings me. It reduces complexity, the code is nice and explicit and it eliminates certain bugs from occurring. But there are a few things that I wanted to discuss regarding functional programming.

Pattern matching got quite an update in Java 19 (although it does require turning on experimental features).

Making illegal states unrepresentable is a good engineering practice. To do this we want to add checks before object creation to make sure it is created in a correct state. Throwing exceptions in the constructor would work for this but it would mean introducing runtime exceptions in your software. If you want to safely create objects without runtime exceptions then smart constructors might be a good solution for you.

Immutability is a good practice with a lot of advantages. One of the disadvantages however is that it is hard to make changes in deeply nested immutable data structures. To circumvent this, Optics were invented and the Arrow library brings these to Kotlin.

Sealed classes are an exiting new feature of Java 17, let’s find out what they are, how to use them and why they are useful.

Recently I gave a talk that included a slide where I briefly discussed single return vs multiple returns. The purpose of this slide was only to give an example of a dogma and basically had nothing to do with the rest of the talk. Therefore it was kinda funny to see that this particular slide caused a lot of discussion afterwards, so it seems natural to write a blog about this topic.

So…​ should a function only have a single return statement or is it better to allow multiple returns?

Kotlin data classes and annotations go really well together, but it is easy to mess it up.

Lamda expressions were introduced in Java 8 and have been around for a while. They are in my opinion one of the better features of Java 8, allowing for a more functional approach to writing code, and thus enabling most of the java 8 features. So let’s take a closer look at lambda’s and see what they are, how to reason about them, and why they are a good addition.

I have seen the following pattern appear quite a lot:

Here the function is called with a nullable argument, and if the argument was null, the function will return null, and if not it will return a proper value. I do not like this, and here is why.