DEV Community: Stefan Fachmann

F# vs C# 3 — Conclusions

Stefan Fachmann — Wed, 03 Jun 2026 15:56:59 +0000

What can I say.

Anyone claiming that F# is good mostly for finance and data processing and C# for everything else, has probably never written a single line of practical F# code.

In previous two parts of the article, I tried to demonstrate that with F# you can achieve the same goals as with C#, but with less verbose, repetitive, structural code.

How it started.

At some point, developers realized that global state with unrestricted data access causes many side effects, producing insecure, error-prone, and hard-to-maintain code as software grows larger. That is when the idea emerged to bring data and the code operating on it together into a single unit, restricting direct access to the unit’s internal state and making software more secure and predictable. This is how data encapsulation was born.

Alongside encapsulation, abstraction was introduced — the process of hiding how behavior works.

Encapsulation (hiding data) and abstraction (hiding behavior) remain two foundational pillars of Object-Oriented Programming.

And that is how OOP has worked ever since — developers bring data and behavior together (classes) and define abstractions for them (interfaces).

For example, for C# developers — including myself — this has become a daily routine. And we rarely question it, because OOP languages like C# leave us little choice but to structure code this way.

But if you ask yourself whether this repetitive routine is always necessary, the answer is — no.

You don’t need OOP concepts to build stateless, streamlined request–response, data-processing pipelines, because in such systems there is no long-lived state to hide and protect. You have a request, and almost immediately you have a response. After that, everything is gone.

That is what I tried to demonstrate in the first two parts of this article by applying FP concepts.

And even if you have a classical desktop application, you don’t always need to approach it in an OOP way. Functional programming handles side effects not by hiding state, as encapsulation does, but by eliminating mutable state altogether.

So, no mutable state:

no need for data encapsulation
data is naturally tightened to the FP code operating on it
no side effects — calling the same function with the same input always produces the same output

Ironically, these FP concepts existed before the rise of OOP, but they did not initially find their way into the mainstream. Only now, after many years, are they becoming more widely adopted.

This explains the emergence of patterns such as Functional Core, Imperative Shell and functional-style OOP, which attempt to combine FP and OOP.

Just think of the amount of FP features Microsoft added to C# to make it more FP like — delegates, lambda expressions, LINQ, expression-bodied members, init-only setters and records (with unions to come next) to mimic immutability, advanced pattern matching, etc.

But:

Generic delegates with Func and Action combined with lambda expressions are verbose, boilerplate-heavy and often hard to read and write LINQ is another attempt to introduce FP concepts into C#, but it is still relatively verbose
Expression-bodied members and init-only setters are attempts to introduce immutability, but they remain verbose and often boilerplate-heavy
Tuples, records, and upcoming unions are attempts to introduce algebraic types. In case of record type, it is just syntactic sugar compiled as a class under the hood, automatically generating init-only properties for you, making positional records strictly immutable by default. Yet, if you add a new non-positional property to it, without initializing it, the compiler won’t complain and your application will potentially crash with a NullReferenceException. Not so with true algebraic data, with compiler strictly enforcing that all data pieces exist and are fully initialized.

This is where F#, a multi-paradigm but functional-first language, comes into play.

By multi-paradigm, I mean you can use both FP and OOP.

However, functions are the core of F#. Defining a function is as simple as: let add a b = a + b.

In F#, immutability and strong type checking come naturally.

So again, F# is FP-first. That is its primary purpose, and you should stick to it. Don’t misuse it to fall back into old OOP habits. You can still use OOP when necessary, mainly for interoperability with .NET or for grouping related functionality.

F# is business-logic-first, with structural code pushed to the background. When used properly, you can often avoid structural overhead altogether, as shown in the first two parts of this article.

I mentioned earlier that Copilot can generate repetitive and verbose code. What I didn’t know at the time is that, starting June 1, 2026, Copilot is moving toward usage-based billing based on token consumption.

More verbose and boilerplate-heavy code means more syntactic overhead. More syntactic overhead means lower token efficiency. And lower token efficiency means higher AI token consumption.

When comparing both solutions, it becomes clear that F# is significantly more token-efficient than C#, thanks to its functional nature, concise syntax, and strong type system with type inference.

So, with all the examples and conclusions in mind, I still wonder why Microsoft treats F# like a stepchild. Why is it still a niche language? Why isn’t it promoted more?

It is also up to us developers to promote F# by using it in real-world applications. The more people use it, the more visible and accepted it becomes.

Of course, moving from OOP to FP is not trivial. It requires a shift in thinking. But there are many excellent resources available.

One of the most useful is F# for Fun and Profit.

If I had to suggest a starting path, I would recommend:

I hope this article helps you better understand F#.

So instead of asking whether it’s worth learning F#, just give it a try — as I did.

F# vs C# — Token Efficiency

Stefan Fachmann — Wed, 03 Jun 2026 15:56:41 +0000

In this second part of the article, we will discuss the changes made to the shopping app by adding two more subdomains to make the web application more realistic — Customer and Order.

In our shopping application, we have products, and we have customers who order these products.
Of course, a shopping domain consists of many more subdomains.

However, our focus will be limited to codebase growth and code complexity when introducing new functionality or new subdomains.

Here, we focus on token efficiency — how effectively a programming language can produce high‑quality, maintainable software using the fewest syntactic tokens (symbols, keywords, punctuation), thereby reducing syntactic overhead.

By syntactic overhead, I primarily mean the ceremonial and verbose code that adds structure but contributes little to the actual business logic.

After adding the Customer and Order subdomains to our C# shopping application, we significantly increased the syntactic overhead.

By using a typical C# “Ports and Adapters” style, a lot of structural code was added.

It becomes a highly ceremonial process, where you must declare an interface (port) and then provide an implementation (adapter) for it.

Program to an interface, not to an implementation.

Just look at the diagram below to see how complex our project has become and compare it with the equivalent diagram from part 1.

The code changes are here.

We won’t discuss implementation details, because there is nothing particularly special about them — except for placing an order, which includes more complex business logic.

The main focus is the significant increase in structural code (interface/implementation definitions, dependency injection, etc.) — code that does not directly contribute to business logic.

And the more subdomains we add, the more this structural code grows.

I know Copilot can generate such repetitive code for you.
But the question is — do we really need to do it in an OOP way?

With F# — no.

No, because in F#, each function signature effectively acts as an interface.
Any function can be replaced by another function with the same signature, often in combination with partial application and module naming.

So, if we want to swap a Cosmos DB implementation for a MongoDB one, we proceed in a similar way:

create a MongoDB implementation (similar to the Cosmos DB version)
define an abstraction via function composition and partial application
keep the same function signature and module structure

Then we simply replace the reference from the Cosmos DB project to the MongoDB one — without modifying any domain logic in Shopping.Products.Domain module.

So, what in C# is achieved through “Ports and Adapters” using interfaces and implementations, in F# is achieved through function signatures, partial application, and module organization.

Now back to the F# solution.

I’ve added Customer and Order subdomains and performed some refactoring.

The code changes are here.

In the Product repository, I replaced the generic ‘T with the specific Product type, which should have been done from the beginning.

However, this resulted in the following error:

Value restriction: The value ‘getById’ has an inferred generic function type val getById: (string -> ‘_a -> Threading.Tasks.Task<Shopping.Common.Types.Result<Product,Shopping.Common.Types.ReadItemFailureReason>>)

getById isn’t a function but an identifier bound to a function of type (string -> ‘_a -> Threading.Tasks.Task<Shopping.Common.Types.Result<Product,Shopping.Common.Types.ReadItemFailureReason>>), because getByIdAsync<Product> (getContainer ()) call, returns a function waiting for missing parameters. A typical case of partial application in F#.

The error was caused by the unresolved generic ‘a parameter propagating upward through the entire call chain.

box based getPartitionKey chain:

box accepts 'a
  → getPartitionKey: 'a -> PartitionKey
      → getByIdAsync<Product>: Container -> string -> 'a -> Task<Result<Product,...>>
          → getByIdAsync<Product> (getContainer ()): string -> 'a -> Task<...>
              → let getById = getByIdAsync<Product> (getContainer ())
                              ← partial application, 'a still unresolved → VALUE RESTRICTION

We could fix it using explicit type annotation of string -> obj -> Task<Result<Product,ReadItemFailureReason>> type.

But avoid any type annotations and use type inference instead.

Type inference in F# means the compiler automatically figures out the types of values and functions from how you use them, so you often don’t need to write explicit type annotations. With type inference come such advantages like faster coding, better readability, etc. But most importantly easier refactoring, in case of type changes of for example input parameters.

To resolve this cleanly, I introduced a discriminated union

type CosmosPartitionKey =
    | StringKey of string
    | IntKey of int

so that all types can be resolved at compile time and partial application remains safe across the entire call chain.

Advantages of this approach:

Type safety at compile time — the DU makes invalid partition key types impossible to represent. With box, passing any type compiles fine and only fails at runtime with NotSupportedException.
No runtime type checking — The box version uses :? type tests — runtime reflection. The DU version is a straight pattern match, resolved entirely at compile time.
Exhaustive checking — The compiler warns you if a new DU case is added (e.g. BoolKey) but getPartitionKey is not updated. With box, you’d silently hit the raise branch at runtime.
Eliminates the generic leak — As discussed, the DU gives getPartitionKeya concrete signature, making the entire call chain safe for partial application.
Removes the defensive raise — The box version needs a catch-all | _ -> raise(NotSupportedException(…)) because any type could be passed. The DU version has no impossible cases to guard against.
Self-documenting — The type CosmosPartitionKey in the signature immediately communicates the intent and valid inputs — no need to read the implementation to understand what is accepted.

DU version moves all validation from runtime to compile time, thus eliminating an entire class of bugs, especially runtime bugs.

Below is how DU based getPartitionKey chain looks now:

getPartitionKey: CosmosPartitionKey -> PartitionKey   ← concrete, no 'a
  → getByIdAsync<Product>: Container -> string -> CosmosPartitionKey -> Task<Result<Product,...>>
      → getByIdAsync<Product> (getContainer ()): string -> CosmosPartitionKey -> Task<...>
          → let getById = getByIdAsync<Product> (getContainer ())
                          ← safe, CosmosPartitionKey is concrete → NO VALUE RESTRICTION

Make illegal states unrepresentable.

This is type-driven development — you model what exists and what is valid in your domain as types, and the compiler enforces correctness throughout. The correctness of your business logic is therefore guided and enforced by the model design.

In C# type-driven development is also possible. But is very verbose because of the type system. Which in newer versions of C# tries to mimic F#’s type system by introducing records, pattern matching and recently discriminated unions. But all this are just syntactic sugar, which has little to do with algebraic types or real power of F#’s pattern matching.

Now let’s compare the number of projects in C# and F#.

We have 20 in C# against 8 in F#.

There is a significant increase in C# projects and files, because in C# we need:

separate projects per layer/concern (interfaces, implementations, adapters) to enforce dependency direction
explicit separation of abstraction and implementation — every interface needs a concrete class separately declared and registered
explicit class/interface declarations for every abstraction (no structural/implicit typing)
dedicated files per type (one class/interface per file convention)
DI wiring boilerplate in Program.cs binding interfaces to implementations
DTOs + mappers per domain as separate types and files

The number of files in C# solution has also significantly grown, because C# (and OOP in general) encourages separation of concerns where each file/class a single responsibility.

Idiomatic F# does not force abstraction-to-implementation separation as a structural requirement. Interfaces and classes are mostly used for .NET OO interoperability,

Below are C# and F# Order services for comparison, as most complex service for now.

Notice, in F# version there are no abstraction-to-implementation separation, class and constructor declarations, and no DI. As with Product repository, we abstract/hide the implementation in Customer and Order repositories by again using partial application.

So, without abstraction-to-implementation separation, there is no need for separate projects per layer/concern with additional explicit separation of abstraction and implementation and no need for DI. Therefore, there is less structural syntactic overhead. Therefore F# code is more token efficient.

Take a look at the place order business logic. Notice how elegant recursion, pattern matching, and piping make the F# implementation. Conversely, the C# implementation looks cluttered with sequential loops, conditional checks, and exception handling.

In Program.fs we still have initially scaffolded starter F# code.

Unlike Program.cs which contains a lot of changes because of two new subdomains.

Below is a new detailed diagram of the web API with all its dependencies, after adding the two new subdomains. Compare the previous version in part 1 of the article.

Once again, dependencies are module-level with direct project references. The domain orchestrates calls to repository modules rather than interface implementations. There is no need for structural code.

There is also the reason why we have less files in our F# solution. Because F# is based on modules, where we can have separate modules for data and modules for functions operating on that data. Or we can have modules which include data and functions operating on that data. We can still separate concerns, but we do so at module-level.

Also compare high-level diagrams with the second one reflecting domain changes.

High-level diagram after Customer and Order subdomains were added
Even after adding two new domain layers, Customer and Order, all three domain layers still reference repository projects directly and use module functions as contracts (no explicit .NET interface projects).

Now you can clearly see:

With less F# code, you can achieve the same result that requires significantly more structural and repetitive syntax in C#.

That is exactly what token efficiency in a programming language means.

And this isn’t the final conclusion.

In part 3, I present more opinionated conclusions about F#.

F# vs C#

Stefan Fachmann — Wed, 03 Jun 2026 15:56:22 +0000

This article is dedicated to F# language, more precisely how it is compared to C#.

Writing this article was motivated by my love for functional programming, and particularly for F#. My first contact with F# happened more than 10 years ago. Since then, I periodically came back to do something with F#. Mostly reading new F# documentation and articles dedicated to F#, doing small F# projects, and reading endless "Is F# worth learning" questions on Reddit, Quora and other sources.

At some point I got pissed off by all this, especially of "worth learning" questions, and decided to give F# a real try. So, I picked up one of our C# projects (.Net Web API) and started reimplementing it in F#.

That is when I really realized how functional programming style and F# type system was superior to C# OOP and its type system. Nothing against C#. I consider it to be one of the best object-oriented languages.

And C# also has some functional features. But they seem like foreign bodies unnaturally glued to C# OOP style.

Below is a simple square operation written in both F# and C#, to prove the point.

let square x = x * x

and here is C# equivalent

public static class MathHelpers
{
  public static T Square<T>(T x) where T : struct
  {
    dynamic d = x;
    return (T)(d * d);
  }
}

While it takes eight lines of code to declare a simple square operation in C#, F# achieves the same result in just one. By leveraging automatic type inference, F# removes the need for explicit type declarations and generic math constraints. You don't have to cast generics to dynamic variables or wrap everything in a class - you simply write the logic and let the compiler handle the ceremony.

Why do we need in C# a class definition to be able to define a simple math operation? why do we need this boilerplate code?

So, with those questions in mind, back to my Web API project.

It is a .Net Web API three-layer microservice hosted by Azure, doing CRUD and searching operations in a Cosmos DB, with relatively large code base.

So, I just wrote a simple typical .Net Web API doing Cosmos DB and Blob Storage CRUD operations - with an exception filter, DTOs, business models and some mappers. It is a functioning web app with not much business logic. The intent was to just prove my point.

The code can be found here.

Here is a detailed diagram of the Web API with all its dependencies.

As you see, each implementation is decoupled via an abstraction. You know

Program to an interface, not to an implementation.

So, the question again - do we always need the complexity of defining abstractions and their implementations? And do we always need this ceremonial interface and class definitions, with repetitive dependency injection, to execute a piece of code? Particularly in this concrete example. And particularly when using scoped and transient services.

Is it worth defining interfaces and class implementations for services which live a couple of milliseconds or even seconds. A scoped service's life begins when the request starts and ends when the response is sent. Transient services have no scope - they're created every time they're resolved, even multiple times during the same request.

I know Copilot Agent can generate code for you. The real question is - do we need to define complex objects with dozens of methods if we only call one or two of them per request. One of the main purposes of OOP is encapsulation of data and methods which work on that data. And probably makes sense for long living objects, for example in a desktop application, when using for example UI components.

We have singleton services in .Net web applications. But they must be thread safe and relatively lightweight.

This is where F# comes into play.

I don't intend to make an introduction to F# here or to explain any of FP or F# concepts in detail. There are many F# dedicated resources out there and one of them is F# for fun and profit.

I just want to show how much easier and faster it is to do the same stuff in F# without OOP corsets of C#.

The code can be found here.

And here is the detailed diagram of the web API with all its dependencies, and much less complexity compared to the C# project.

As you notice, there are only module-level dependencies. The domain logic calls repository modules directly, rather than calling interface implementations.

First, I want to compare Program.cs with Program.fs

In Program.cs we register a lot of services with the built-in DI container. Including our own services and their corresponding implementations to be able to inject them later in our constructors.

In Program.fs we still have initially scaffolded starter F# code when selecting a Web API template, and no service registrations. Explanation later in the article.

Second, let's compare the number of projects in C# and F#. We have 8 in C# against 6 in F#. And the reason for that is that I have implementations and their abstractions in one place. So, there are no separate class libraries for abstractions, and their implementations like in C#.

Let's look at the implementation for our Blob Storage files repository:

And below I have the abstraction:

And what is interesting here is the latter.

I abstract the implementation away by using partial application, a functional programming technique where we take a function with multiple arguments and pre-fill some of them, producing a new function that takes the remaining arguments.

So pre-filled here is BlobServiceClient service, the specific implementation of Blob Storage repository. And with the help of partial application, we can abstract the implementation away by hiding the implementation details, as I do here with BlobServiceClient which is used to access Azure Blob Storage.

So, now I just need to open the Shopping.Files.Repository.Product module, under our Shopping.Products.Domain module and voila you can call the abstraction.

There are no implementation details when calling the abstraction, because it is hidden by partial application. And it is clear what implementation will be called because of the opened full module path, which provides the necessary context. And there is no constructor with dependency injection because there is nothing to inject. Therefore, no service registrations with the built-in DI container are necessary -for our services.

I still use a built-in DI container in our Blob Storage repository project, to create a BlobServiceClient singleton and provide it when necessary.

In a typical ASP.NET Core app the DI container is built once at startup by the host builder and reused. Here, because this module is standalone, the lazy ensures the same behavior - deferred construction and single instance - without relying on the web host. If we were already inside the web app's startup, we'd normally register BlobServiceClient in ConfigureServices and resolve it via the host's provider; the lazy pattern is mainly useful when we're outside that lifecycle (e.g., library, script, or manual invocation).

I could of course just create an instance of BlobServiceClient and provide the cached instance, because of lazy block, when necessary. I use the built-in ID container with generic capabilities in case I want to register more services. Anyway, the creation of BlobServiceClient is encapsulated in the repository itself for further use, thus completely decoupling it from Web API project.
Now compare this with code overhead needed to achieve the same result in C#.

We have file repository abstraction

We have the implementation, with a base class

And of course we have to inject then IProductFileRepository dependency in order to use it

C# adds a lot of syntactic overhead - with all the abstraction and implementation definitions and the required dependency‑injection setup - compared to F#, even for simple file‑related operations.

That's all for now.

In part 2 we will extend the example with Customer and Order business domain and new implementations, and and talk about token efficiency.