"Why don't you just use F#?"

I often see this phrase pulled out when people are sharing lang-ext on twitter, or if the project ends up on Reddit, or on the front page of Hacker News. It's as though the person writing it assumes all programmers are working on greenfield projects and have total freedom to write in whatever language they like. In which case, why not Haskell? It's better than C# and F# combined.

The reason I wrote this project is because I am the CTO of a software company in London, and we have a project that's well into 15 years of development. It is a C# project and it is now enormous. Over the years of developing this project I have come to see the pain-points of OO up-close and personal. Pain points that only really show themselves when a code-base gets to a certain scale (they're always there, but they're cognitively easier to deal with when the projects are smaller). I had previously fully bought into the idea of OO, and I proudly proclaimed that the Design Patterns book was my favourite programming book. Not any more.

When LINQ made an appearance in C# I sat up and started looking into this functional programming thing a bit more. I slowly started bringing ideas into the project, and eventually we started using F# for satellite projects, or areas of the app that we scheduled for a refactor. The problem was that the core of the application was still very much OO, and very much suffered from it. There was no functional framework for C# like there is in F# (immutable collections, monadic types, referentially transparent BCL functions, etc.). So we'd have lots of lovely F# code, sitting there, being all reliable and not code-rotting; and then we'd have the C# code that was throwing up null reference bugs (and the like).

I felt from spending time using Haskell and F# that I'd seen the future of software development for large applications, and it frustrated me that I couldn't use it to improve my existing code base (without a full rewrite which is super dangerous for any project, but it would also represent years of work for the dev team). And so language-ext was born.

The goal of this project is to:

• Improve the safety of programming in C# (protecting against null reference bugs, immutable collections, etc.)
• Direct the inertia toward using functional technique by making it cognitively easier to do that over OO technique
• Improve and make safer the concurrent and parallel programming story in C# (beyond TPL)
• Smooth out the interop between C# and F# projects, which is pretty dire by default FSharpOption isn't the safe type it should be in C# (for example)

Going back to the original "Why don't you just use F#?". There are other reasons where language-ext is valuable:

• You work at a company that won't accept another language, and insist on C#. Or you can't convince other devs on the team to learn a new language. So this is a way to get functional concepts into C# code.
• Not everyone likes the F# syntax style. I personally love it, but there are plenty of people who don't. And therefore having a functional C#, with all the quality tooling that comes with it (F#'s tooling is still sub-par compared to C#) is compelling.
• C# is a functional language. This might seem like an odd statement. But F# is also an OO language. It's just that C# is OO first, and F# is functional first. C# has first class functions, monads, lambdas/closures. It will soon have pattern matching, record-types, and possibly discriminated unions. C# is becoming more of a Scala-like language. So it needs a coherent set of functional libraries.

At best I think it's naive to say "Why don't you just use F#?", not everyone is in the perfect development environment; at worst it's trolling.