Our Experience with Bi-temporal Event Sourcing


Bi-temporal event sourcing combines storing data as a sequence of events, which tell what has happened with the data, and the data has two associated points of time, one when the data entered the system and one when the data takes effect. This post is about our 8+ years of experience with bi-temporal event sourcing, along with code samples showing how to achieve this. Feel free to skip the code blocks and just read the conceptual parts. But you’ll miss the beauty of F# 馃槀 This post is part...

Myths about F#: Code without type annotations is hard to review! No, it’s a relief.


After one of my presentations about F#, we had a discussion about the effect of type inference, resulting in almost no type annotations, on code readability and reviewability. The concern was that it makes the code harder to understand, especially when reviewing code, for example, outside of an IDE (GitHub/Azure DevOps/… Pull Requests).

So is there a problem or not? Let’s see.

Today’s random F# code: Using measures to give types more meaning


We use NodaTime in our application to deal with time. As you may remember, time is very important in our application – it’s a attendance time-tracking tool with duty planning and many more features. For example, we use Instant to model a point in time. But sometimes, we need a point in time with a granularity of minutes, not nanoseconds. Instead of introducing our own type to model an instant with minute granularity, we use an Instant with a measure. Let’s see how this works:

Myths about F#: F# is hard to learn! No, it’s just different than C#.


A typical conversion: Me: “Did you take a look at F#?”Paul*: “No, it’s just too hard to learn!”Me: “Why?”Paul: “I don’t understand anything because of the syntax.” *Paul = Person assuming unyielding learning F# isn’t hard to learn. But you probably have to learn four concepts that you may never have seen before** **unless you have experience in other functional programming languages Let’s see these concepts and how you can...

Myths about F#: We can’t use F# because we can’t rewrite everything from C#! You don’t have to, use Interop.


Most code running on .Net is written in C#. So when you consider writing some code in F#, you probably already have a good amount of C# code. C# code you want to keep. It probably doesn’t make economic sense to port C# code to F#.

The good news is that you can start using F# anyway. F# and C# have excellent interoperability.

Recent Posts