Contrasting F# and Elm’s record types

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

Having spent some time this week with Elm I have seen plenty of things to make me like it, a more in-depth review of my experience with Elm so far is in the works but for now I want to talk about Elm’s record type and how it compares with F# record type which us F# folks rely upon so often. At first glance, there are a lot of similarities between the two, but upon closer inspection you’ll find some notable differences.



In F#, to create a record you first have to declare its type, and the idiomatic F# way is to use records as lightweight data containers but you can optionally add ‘members’ (i.e. properties or methods) to your record types too.

Whilst fields are immutable by default, they can be made mutable if you explicitly mark them with the mutable keyword. Whilst this is not an encouraged practice the option is there for you if you need it, usually as an optimization to avoid the GC overhead of using the copy-and-update operation (under the hood F#’s records are compiled to class types so they’re heap allocated and therefore incurs allocation and collection cost), or because you need to interop with C#.

Advantages of using records over classes include the ability to use pattern matching and that they use structural equality semantic. Given their role as lightweight data containers, like tuples, is the sensible choice in most cases but you can still override this behaviour if you need to.

Whilst F# record types can implement interfaces, they cannot be inherited from, a fact that you can argue for or against. Personally I’m on the ‘argue for’ camp as it gives me future guarantee of safety and if I need to support variance I will introduce interfaces and/or use composition instead.



In Elm, a record can exist on its own without you having to first define a type for it. Defining a type merely creates an alias to help make your code more readable and give you some static safety where it’s needed.

Elm doesn’t have classes but its records allow polymorphic functions to be defined as part of the record. However, these are not the same as F# record’s instance members as there is no this or self keywords in Elm (because Elm’s creators consider it an extremely bad practice to mix data and logic, which I imagine most functional programmers will agree).

Unsurprisingly, Elm’s records can be pattern matched, but one caveat I found is that as far as I can tell there’s no way to capture two records with the same field into two different local variables (see example below).


So far we have seen that Elm’s records are pretty similar to their F# counterparts, where things get interesting is the extensibility options you have with Elm’s records.

Extensible Records

On top of the clone-and-update operations (using the | label <- value syntax) you can also:

  • add new fields using the = operator, e.g. { x | species = “Jade Dragon” } adds new species field with the value “Jade Dragon”
  • remove fields by using the minus operator, e.g. { x – age } removes the age field from x when cloning


Composible Record Types

Type aliases defined using the { x | label : type } syntax (like Named and Aged in the above example) can be composed together using a somewhat strange syntax, e.g. Name(Aged {}) which says that the record must contain all the fields defined in both Named and Aged. The inner most { } in this case represents an empty record, you can specify bespoke labels and associated types there or use a type alias that is defined using the { label : type } syntax, like the Character type alias we defined in the above example.


Structural Typing

Finally, Elm’s records support structural typing which allows functions to accept any record that has the required fields, this gives you the benefit of dynamic languages.

In F#, whilst you don’t need to explicitly specify the type of the record when pattern matching (e.g. let showName { Name = name } = …), the type inference process will still choose a type for you so you’re statically bound to a particular type. You can, however, support structural typing in a similar way using statically resolved type parameters which also works on normal class types but you lose the ability to use pattern matching in the process, and I always find their syntax a little clumsy so wherever possible I would use interfaces instead.


Related Readings

F# – Record types vs classes

F# – Referential equality for Record types

F# performance test – structs vs Records

F# – statically resolved type parameters

F# – XmlSerializer, Record types and [CLIMutable]

F# – Serializing F# Record types

AOP – string interning with PostSharp on F# record types

Elm – Extensible Records

Research paper – Extensible records with scoped labels

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter

Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.

Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.

Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.

Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!