One of the great features of .NET is that you can mix its programming languages (C#, F#, VB.NET) in a single solution and that assemblies written in one language can call assemblies written in other languages. This is great, especially when starting with F#. A team does not need to switch everything at once, but can keep using the existing C# code and use Interop to call C# from F# or vice versa.In this article, we take a look at the Interop story in 2026. Spoilers: it works great.
Not having to annotate types for every argument and return value in F# is a big relief. In this blog post, I share some tips and tricks to reduce the need for type annotations.
We store most of our application’s data in an SQL server database. Sometimes, we need to transfer the data locally to debug defects related to production data. The database grows daily, and restoring the database locally takes more and more time. So we had the idea to disable indices because they are not needed for debugging locally, but restoring them takes quite a lot of time. We can’t disable indices before exporting the data to a bacpac file because it’s the productive...
Yesterday evening, I gave a workshop titled “To test, or not to test” at the Software Crafters Zürich Meetup. In the workshop, we gathered reasons to write tests: being confident that the code works, being confident that regressions can be prevented, helping to drive the implementation, and having documentation of the system. Interestingly, when I prepared the workshop, I forgot about the documentation aspect of the tests. Here is why and why it matters.
Welcome to our team! Today is your first day, which means it’s the day you’ll release your first feature. You’ll see everything needed to design, implement, and release a feature in our system. We’ll touch on F# language features, our TDD style, and some architecture topics.
This blog post is part of the F# Advent Calendar 2024 (thanks, Sergey, for the organisation).
Onion, Hexagonal, Clean, or Fractal Architectures aim to organize how we deal with dependencies in our software architectures. But which one should we choose? After distilling the essence of each approach and comparing the advantages and challenges, I’ll show how to combine all of them into an approach to use evolutionary steps towards an architecture that fits your needs from day one until the software dies. You’ll see that layers and slices aren’t enough. A modularisation that fits the domain...
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...
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.
Sometimes, unit tests are really small – so small that they fit on a single line:
In F#, you specify the order of files explicitly. Any code can only reference types, modules and functions that are higher up in the same file or in a file higher up in the file list. When starting with F#, this feels strange because most programming languages don’t rely on ordered files. Some call this feature even dumb.