What we learned running F# in production for 5 years

Date: 2024-12-27 | reflect | fsharp |

Today I'm sharing takeaways from Ian Russell's Celebrating 5 Years in Production blog post, part of the 2024 F# Advent Calendar. Ian is an active contributor in the F# community and author of the (free!) Essential F# book.

The blog post is short and sweet so I'd recommend going over there to read it before coming back here for my summary and takeaways.

Summary:

  • GPS Aggregation SaaS product built with F# over past 5 years
  • At peak it processes 10M signals per day (~116 per second) but the complexity largely lies in its 450 external integrations, each with their own APIs, data formats, etc
  • They chose F# as they were allowed a .NET or JVM lang and wanted functional, eventually choosing it over Scala

What's good about F#?

Relatively simple to learn.

Ian says the team was able to onboard new engineers in a few weeks.

I think F# is a simple language but I would caution that parts of it are not simple and may take newcomers longer to ramp up. Personally I code with F# in a ~rudimentary way mostly leveraging it for great types, immutable values, and its list processing functions. But computation expressions, monads, recursion-first principles etc can quickly make things a lot more complicated so depends on the codebase.

The code is succinct, robust, and performant.

This is part of what makes F# so fun - it kind of forces you into the pit of success such that when the thing compiles it probably works pretty well. I think of it as a great 80% language - it takes the good parts of many langs making it very good at many things though maybe not the best at any one thing.

Related:

F# gets the full power of the .NET ecosystem.

It can use most libraries natively and there are plenty of F# wrappers on popular libraries to make it a bit more ergonomic to work with.

I am honestly surprised sometimes at how easy it is to use C# libraries from F#. You basically can write C# in F# just without the ;

F#'s excellent type system is good for Domain Driven Design which itself is good for building software with limited unnecessary complexity.

I think DDD is a great idea though sometimes hard to implement. F#'s straightforward, powerful type system makes modeling domains easier which I think makes it easier to communicate about.

Related: My favorite book on DDD has most of its examples in F#

What's bad about F#?

Community is small.

This means few libraries, few maintainers.

This will probably impact you less than you think as you have access to the full .NET ecosystem (including all C# libs which is a top 5 lang) but it is true that F# just doesn't have as many F#-native libraries as a top 10 language would. This means there are less libraries that are built just for F# and also that many of the libraries only get updated every now and then. F# is relatively stable so again this will impact you less than in a more volatile ecosystem (like JS where it breaks every year or so) but still a lot less ongoing improvements.

Low adoption remains the greatest risk / problem for F# long-term.

Related:

Hard to find F# developers

This is probably true - F# community is small so not that many people that know F# going in.

Though I would argue there are plenty of devs out there who would jump at the chance to build in F# if given the opportunity and the ramp up is pretty graceful. But fair point - not many F# devs so perhaps hard to find people to use it.

C# libraries are built for C#. .NET is too.

The truth is that C# is a top 5 lang and F# is top 50. There is just less of an audience for F# than C#. And so C# gets more contributions to it.

For the most part this is fine - F# basically gets all the benefits of being a top 5 lang without actually being one. We get free libraries and each .NET release inexplicably makes F# a ton faster.

But there are some downsides as well. C# is more Object-Oriented so some design decisions don't really make sense in F# systems (though F# is incredibly flexible so you can do OO in it just fine). This does mean that some libraries and stuff do need some plumbing on F# side to do the things you want or perhaps the paradigm just doesn't make sense and you have to roll your own.

Again probably will not get in the way of building stuff as much as you think but still F# is just not in the same league of support as C# is.

Would you choose F# again for building a production webapp?

Given the choice - yes. But realistically most companies won't give you that choice / buy in to such a small language in which case C# is a fine choice. It's well supported and is slowly incorporating features from F# allowing you to code better systems.

Personally I've never had the pleasure of writing F# professionally. Everything I use it for is personal projects. My companies always end up using top 10 languages - JS, Python, Golang, etc. So the truth is it'll be hard to find a job using F# and to get your company to use F#.

But that doesn't mean it's not worth using and it doesn't mean it's a bad tech. One of the big reasons I keep using it and sharing about it is because F# is SO much better in so many ways. But I don't have an expectation that F# will eventually win - it's been around awhile and has never (to my knowledge) breached the top 20.

What has happened is that more of the popular languages have started incorporating pieces of these fringe languages to make them better - types in python, LINQ in C#, the rise of Gleam as an alternative for Elixir.

Moreover I've found that working with F# has helped me develop practices that work well in any lang - from biasing immutable to constraining side effects w impure sandwiches to making invalid states unrepresentable.

Ultimately the biggest risk / problem with F# is the lack of adoption. This is a vicious cycle that is hard to get out of. Without more adoption we won't get the hype to warrant more adoption and so F# remains a fringe technology - even though it's technically better in many ways than those more popular than it.

So here I have to agree with Ian:

  • If you can choose F# - do it
  • But you probably won't be able to - so use what you can and take your learnings from F# to try and make the software ecosystem just a little better

Next

Thanks for reading! I'm experimenting with these more reactiony posts again so let me know if you liked it or not or have feedback on how to make them better.

If you've got some time I'd highly recommend checking out the original posts:

If you liked this post you might also like:

Want more like this?

The best / easiest way to support my work is by subscribing for future updates and sharing with your network.