F# makes it easy to model a domain with discriminated unions (= it is one of these values) and measures (type-safe numbers). Excerpt from our expenses sub-system:
Today’s random F# code: Domain modelling with discriminated unions
T
Myths about F#: F# is for math problems only! No, F# is a general-purpose programming language.
M
When I show F# code to non-F#ers, I often get a reaction that goes something like this: “This code looks kind of nice, but we don’t have math problems to solve, so F# is not for us.”
By the way, the code I show typically has nothing to do with math. We don’t solve math problems with F#. We write a business application with it.
So I wonder why I hear this almost every time when I present about F#. Some guesses:
Today’s random F# code: Result instead of exceptions
T
Today’s random F# code from our app is about using Results instead of using exceptions.
Do you often need to get some data from the database, but it’s not sure that the requested data exists? And you don’t like using exceptions for this because exceptions are for really unusual things? Then use a Result:
Querying data with the help of Result
Today’s random F# code: validation
T
Today’s random F# code from our app is about validating data passed to us over our public API:
Example code showing the usage of FsToolkit.ErrorHandling’s validation computation expression.
Myths about F#: C# will become F# anyway, so we don’t need F#! Nope, not happening.
M
C# indeed gets more and more features known to F#, like pattern matching, switch expressions, records, a way to deal with nulls, and someday maybe even discriminate unions and deep equality on collections. Maybe even type inference could become as powerful as in F#. However, C# can’t eliminate the features it already has, like mutability by default and statements. Immutability by default and expressions-only are strengths of F# and make building error-free apps easier. Real pipes and...
Today’s random F# code: Type inference
T
Today’s random F# code is about type inference. If you like var, default and new() in C#, you might like F# a lot because F# gives you type inference also for function parameters, return types and generics (grey = IDE showing the inferred function signature):
F# type inference examples
Our journey to F#: The effect of F# on our (unit) tests
O
On our journey from C# to F#, we were at a point where we changed our (unit) testing strategy. Our approach just didn’t feel right anymore. We struggled to do TDD because we didn’t get the tests to fail first. We wrote tests that didn’t increase our confidence and started thinking of them as waste.
This post is part of the F# Advent Calendar 2021
Thanks to Sergey Tihon for organising the Advent Calendar.
Pimping Unquote
P
Unquote is a great library for writing test assertions in F#. In our acceptance tests, we frequently check data structures for equality. When these data structures get bigger, reading test failure messages gets harder. That’s why I implemented an F# data structure differ around Unquote that lets me quickly see the differences.
Type-safety across .Net and TypeScript – Testing JSON serialization and deserialization
T
This is part 7 of how we generate types from our .Net backend to be used in our TypeScript client. Why do we even bother?Generating TypeScript constants from .Net constantsFinding the types used in communication between the .Net backend and the TypeScript clientGenerating TypeScript classes from .Net typesGenerating Angular Services from .Net WebApi ControllersTypeScript-friendly JSON serialization of F# typesTesting JSON serialization and deserializationPutting all the parts together In the...
Our journey to F#: making async understand Tasks
O
In our F# code, we have a lot of asynchronicity: query the DB, call external services, write messages to the service bus, etc. Inside of our happy F# bubble we use async workflows, either by using Async or by using the computation expression async { ... }. But we are surrounded by a world of Tasks. So we often need to call functions or methods that return a Task. Of course, that is no big problem, we can just add |> Async.AwaitTask, but that leads to a lot of visual clutter in our precious...