Why F#?
(batsov.com)438 points by bozhidar 3 days ago
438 points by bozhidar 3 days ago
> felt too much .NET-y and too much MicroSoft-y
That was kind of my main problem with dotnet stack in general, although that was some years ago. I've tried sneaking F# into our project by building set of tests (the main codebase was in C#), but some of my teammates would have none of that.
My personal perception of the dotnet community was that developers either were too pigheaded about doing things "the Microsoft way", or hyped about "innovation" — "Oooh... check this out, Scott Hanselman made a whole new conference talk about it...", and then you'd look into this "innovation", and it often turns out to be some decades old, well-known thing, only "wrapped into MSFT packaging", which is not really bad by itself - it just seemed that people didn't actually use them in a practical way. I just never found that sweet-spot between pragmatism and excitement. You have to find a middle ground between: "This works! Sure, yeah, but isn't it darn ugly and probably not scalable?" and "This is so beautiful, and cool, but nobody besides Jeff really understands it." And my personal experience was that .net programmers would always want to be on one of those sides.
You get speed of development, productivity, lots of libraries. You get something that is easy to learn and understand.
F# is a very well-polished functional language. Think of it to Haskell as C# is to Java. No worries about space leaks or purely-academic syntax or monads (though you can get those if you need them). All with tight integration into one of the biggest, well-established ecosystem (CLI). It's managed by smart people who know how to keep it from derailing as it grows.
Coming from a .NET developer - why NOT F#?
* Network effect, or lack thereof. Very few people use it. * Its nature is contrary to the ecosystem. The CLR is fundamentally resistant to the paradigms that F# creates.
Wonderful little language - one of my favorites - and we owe a lot to it for the great features that C# has. But it just hasn't picked up the critical mass it needs.
In the case of F#, the use cases are diminishing with every new C# release, since C# is getting better and better at the things F# is supposed to be strong at (record types, pattern-matching, etc.). Better to write the thing in C# using modern features of the more popular and capable language.
Not sure that C# is the more capable language - its still that F# is mostly a superset of C# although C# is catching up. I think they are on par w.r.t capability (i.e. CLR compatible). In terms of conciseness, and expression F# still wins IMO; and given some of the extra features can be more performant at times (e.g code templating/inlining vs just JIT attributes). Custom CE's (Async/TaskSeq), nested recursive seq's great for algorithm dev, DU's, etc. There's a lot of little features C# doesn't have (or don't quite fit) that when I write C# I'm forced to implement still more cruft code around.
IMO its generally more readable as well to non-dev than C# and to dev's outside the Java/C# ecosystem (e.g. Node, Go, etc). I've shown F# code back in the day to non-tech stakeholders and they typically understand it (e.g. data modelling).
Unions remain the killer F# feature missing from C#.
Also, basic object initialization in C# has turned into a nightmare with recent versions. You need a flowchart to select among the 18 syntax options which suite your current needs.
With F# (and other newer languages), record fields are either `T` or `T option`. No need to worry about whether the value needs to be computed in a constructor and then remain immutable, whether it needs to be initialized by an object initializer and/or a constructor or not, whether it needs to remain interior-ly mutable throughout the life of the record, and so on. (Although as I recall you do still need to consider null values assigned to non-nullable references in your F# code that consumes C#.)
There's a draft spec out there for discrete unions in C# fwiw. I wouldn't be surprised to see it in another version or two.
And while I agree that I don't love some of the object initialization patterns C# allows--I respect that other people might have different style than me and don't mind ignoring that those styles exist when writing my own stuff :)
My general rule goes something like:
1. Use record types for any simple data structure
2. Avoid using primary constructors (even on record types).
3. Use { get; init; } properties for everything unless there's a good reason not to.
4. For things that need to carry internal state, have different methods for mutations, emit events, etc., use a class with regular old constructors and either { get; } (for immutable) or { get; private set; } (mutable) properties as needed.
You may start to get a point when C# gets a two-directional type inference system. As it's now, any functional-looking code requires so much boiler plate that it's shorter and less bug-prone to copy your functions code everywhere you want to use them.
Just try to make any generic high order function in C#. Any one you can think of.
Using OneOf library or something similar instead of discriminated unions / sum types.
Trying to use a functional pipeline instead of DI.
F# can be nicer to use for a functional programming style.
It's not always about the features such as keywords, built-in functionality and types. It's also how language features work together.
C# is more fit for an imperative or OOP style when F# is more fit for a functional style.
F# on front page? And popular?
ahhh, Its April Fools?
JK, I love F#. Please get over the hump and be a big language.
> Why F#?
I'm kinda wondering if anyone here with decent C#/.net experience can give their version of the answer?
---
The article really didn't answer its own question. It basically says "How" instead of "Why"...
...Which as someone who's spent over 20 years in C#, and tends to advocate for "functional" style, leaves me with more questions than answers!
I've worked with .net professionally for almost 20 years. At the beginning with C# while last decade almost exclusively with F#.
F# is just a better language. Simpler, more concise, more readable with stronger type safety. I will never go back to writing C# as I'm finding it too frustrating at times and unproductive.
Everything is an expression (i.e. its an actual functional programming language), and along with it comes a different way of thinking about problems. Coupled with a really good type system which has discriminated unions, you'll have much fewer bugs.
Pro tip: don't write F# like you would write C# - then you might as well write C#. Take the time to learn the functional primitives.
if I may elaborate on "everything is an expression," F# allows you to do things like (with apologies for being a tad rusty with the syntax)
let bar =
if foo then
7
else
11
let bar =
try
// code that might throw
7
with ex ->
11
Whereas in C# you have to do like
int bar;
if (foo) {
bar = 7;
} else {
bar = 11;
}
Except that most C# developers do
int bar = 0; // or some other default value`
This doesn't seem like a big deal given these examples. But it becomes a much bigger deal when the if/else grows super large, becomes nested, etc.
Ah yes that is definitely a nice addition to the C# language, albeit still with a couple of shortcomings compared to F#:
1. It doesn’t support code blocks, so if you need multiple lines or statements you have to define a function elsewhere. 2. To get exhaustiveness checking on int-backed enums you have to fiddle with compiler preprocessor directives.
And for #2 any data associated with each enum variant is left implied by C# and has to be inferred from a reading of the surrounding imperative code, whereas in F# the union data structure makes the relationship explicit, and verifiable by the compiler.
A nicer, cleaner and simpler syntax, superior pattern matching, active patterns, discriminated unions and computation expressions
Can it do GUIs well?
I don't know if I would say 'well'. For simple GUIs it's OK but, for non-trivial GUIs I would use the approach to write the GUI frontend code in C# and have it call the F# 'backend'. If for no other reason than that the support and documentation for doing GUIs in C# is much better.
How about mobile?
Never tried, but I'm guessing more or less the same story as above. I would probably start by looking into .Net MAUI for that.
And how does it compare to e.g. Scala?
The biggest difference is that Scala is a much bigger and more of a multi-paradigm language. F# feels smaller and more focused and on its ML roots and functional programming. Not saying that Scala is less 'functional' than F#, but Scala supports you writing your code in a much more OOP way if you want. Yes you can (and sometimes have to) do OOP in F#, but it doesn't feel natural.
Because it's a CLR language, it has access to all the same technologies as C#. That is, all the Microsoft native ones plus cross-platform with Avalonia.
For web UI we have Fable and it's integration with well-known js frameworks, also WebSharper (although it's less well-known) and Bolero (on top of Blazor)
For mobile we have FuncUI (on top of Avalonia) and Fabulous (on top of Avalonia, Xamarin and Maui). Most of these frameworks use Elm architecture, but some do not. For example I use Oxpecker.Solid which has reactive architecture.
Can't help with Scala comparison, but at least DeepSeek V3 prefers F# for UI https://whatisbetter.ai/result/F%23-vs-Scala-9eaede00c7e4485...
It can do GUIs well, although it takes some finesse to manage user state in an immutable-first language. Check out Fable for building web apps: https://fable.io/
I don't have much experience with Scala, but I think the two languages are pretty comparable in their respective ecosystems. The biggest difference I'm aware of is that Scala has typeclasses and F# does not.
F# is not really that strong on immutability, though. Sure, variables and struct fields are immutable by default, but making them mutable is one keyword away. Similarly with classes - declaring readonly properties is more concise, but when you need a read/write one, it's readily available.
I am also a C# dev and haven't worked on a Windows machine in 5 years.
C# and F# both work fine with Rider or VS Code on Mac or Linux.
Does anyone else find interesting that people who write blog posts saying "my favourite language is X", it's never a mainstream language..?
Successful language designers select for what's popular, not what's good.
C++ intersected the mass of C programmers with the new OO fad, and kept all of C's warts. Had Stroustrup made C++ better, he wouldn't have an army of adopters who already knew C. Maybe merit will win out in the long run [1]? I'm not hopeful.
Java needed to be close enough to C++, and C# to Java. And Brendan Eich joined Netscape to "put Scheme in the browser".
[1] https://www.theregister.com/2025/03/02/c_creator_calls_for_a...
My favorite language is Python, but I wouldn't write a blog post about it because no one would care.
My favourite language is also python, and I would love to read your blog post on why your favourite language is python :-)
Same as many, I had wonderful experience with F# in the past, I would use it again if:
- fable would 100% detach from dotnet - keeps up yo the LLM rush, specially vibe coding on cursor
Last LLM experience it generated obsolete grammar (not much but a bit).
Such la gauges are key for vibe coding experience and modeling.
As a person who's worked with the author (a great guy!) and with the F# community on a very large F# project: don't bother with F#, professionally speaking.
F# has many theoretical qualities, which make it fun if you like these things, but it also has some fundamental flaws, which is why it's not getting a wide professional adoption.
- the build system was a mess last I checked (slow, peculiar)
- syntax is not c-like or python-like (a big deal for a lot of people)
- you can't hire developers who know it (and certainly the few are not cheap)
- the community is a bit weird/obsessed/evangelizing (a turn off in a professional environment)
- it's clearly a second class citizen in the .net world (when stuff breaks, good luck getting support)
On the other hand
- it has discriminated unions
- units
- etc.
but do you need this stuff (not want: need)? most people don't.
The build system is exactly the same as C#, MSBuild with its .NET SDK, and syntax and community are entirely subjective; F# has the least weirdo community I've personally seen for an FP language. Weak arguments to say the least.
I'll give you the chicken-and-egg hiring problem and it being second-class to the .NET team, though; I'd add poor IDE support by modern standards, only Rider feels right. I love F# but I've moved on for these reasons.
People will do anything except actually try Elixir. :D
...I mean: pipes, immutability, transparent mega-parallelism... helloooo?
I tried F# some years ago (after I was fired from a shop that decided they will go all-in on Java and F# and dropping everything else overnight) and I was not impressed. I mean the language is really nice but the C# baggage and runtime was just a bit much. And I was not left convinced that immutability alone is worth the switch. I suppose we can call F# an FP gateway drug?
Now arguably you get a runtime and some baggage from the Erlang runtime (the BEAM VM, where Elixir also runs), but the guarantees and features you get are invaluable, and have proven themselves many times over the last literal three decades.
Yes, I agree that it's a big drawback.
Elixir made me more productive and gave me back my love for programming, and I work with it professionally for 9 years now. But the lack of static typing is getting so irritating that I started upping my efforts to get [even] better at Rust lately.
So I agree. It's one of the very top drawbacks of Elixir.
> Elixir
For me, it's Erlang. I just really like its horn clause syntax, it's so clean and readable. I know a common complaint is lack of piping (and even though you can implement it trivially, the order of arguments for some functions makes it of dubious use) but it's a small price to pay.
> I mean the language is really nice but the C# baggage and runtime was just a bit much
This was my experience with F#. Frankly, I've never been happy with my experience with CLI on Linux, and the toolchain inherits a lot of baggage from its C# heritage. Microsoft's toolchains have a very distinct workflow to them. F# has some interesting aspects to it like active patterns (something I wish was more common in the ML-family), but tbh I'm more than happy with ocaml.
I can't remember which version of Erlang was the most current when I started learning Elixir, but I do know that it was years before OTP 20, which fixed its string issues. Prior to that, Erlang didn't have very good string support for internationalization (I do a lot of Japanese language programming). Elixir, on the other hand, did. Otherwise, I may have gone with Erlang back then.
I like Erlang a lot, too. Both are great languages.
If one need to get on Beam, is it better to start on Elixir or Gleam?
Elixir's ecosystem is much farther ahead than Gleam, so if you want to actually achieve stuff without pauses to fill the gaps yourself, then Elixir is the way to go.
And don't get me wrong, I love the idea of Gleam, a lot (Rust syntax, strong static typing, what's not to love?). But my PL early adopter days are over.
This isn't such a big issue in my experience. Auto-formatting helps a lot, the code needs to be just syntactically correct.
The default F# autoformatter is bundled/supported by VS Code, VS and Rider [0].
[0]: https://fsprojects.github.io/fantomas/docs/end-users/StyleGu...
F# has both "lightweight" (indentation-based) and "verbose" syntax. If you don't like significant whitespace, you can just use the latter.
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
That's an interesting idea and implementation.
I don't think being whitespace-significant is a "hard pass" dealbreaker, but as someone who's not a fan of it, I'd say this only goes a small way towards alleviating that - like most "choose your preferred syntax" designs. Even if you're a lone-wolf developer, you're gonna end up reading a lot of example code and other material that's in the ugly whitespace-sensitive style, given that:
> The verbose syntax is not as commonly used ... The default syntax is the lightweight syntax.
And most people in practice are not lone-wolf devs, and so the existence of this syntax helps them even less.
> Static typing removes the downside of whitespace.
How so?
> Oh, and every language with line comments (so most of them) has significant whitespace.
Technically true, but that's not what people mean by "significant whitespace" in this context. So you're being pedantic rather than saying anything meaningful.
But you made me think. The ultimate nightmare would be significant trailing whitespace - the spaces and/or tabs after all the visible characters change the meaning of the line.
In f#'s case, there is the trifecta of everything being an expression, static typing and default immutability. This means you often write code like this:
let foo = if bar then baz else someDefault
Due to it being an expression you assign what the if evaluates to to foo. Due to static typing, the compiler checks that both branches return the same type. Due to the default immutability you don't declare and assign in separate steps. What this results in, is that accidentally using the wrong indentation for something usually results in an error at compile time, at the latest.
Compared to how python does significant whitespace is that it's dynamic typing + statement based, which means you can easily end up assigning different types to the same variable in different branches of an if, for example.
I hope I explained it in understandable terms
> How so?
Well I don’t know what issue you have with whitespace, but the usual complaint is that programs with small typos are syntactically valid but logically incorrect. This is why CoffeeScript became so disliked. A static type checker makes this scenario much less likely since it won’t compile.
I would also add that F# has some indentation rules (“offside rules”) and tabs are disallowed, further shrinking the input space.
It's pretty baseless to claim that modern dotnet is inherently shitty. They've made tremendous strides in the dotnet core era.
F# making you unemployable is debateable, but I don't see what makes F# any less employable than most other FP languages. They have some niche applications that make it useful rarely, but when they're useful its a terrific tool for the job. F#'s ability to interop with the rest of the dotnet ecosystem positions it better than most functional languages for business usecases.
I don't have any problem with the idea that Microsoft's technologies are "shitty" after all the response of my work laptop to its mandatory Windows 11 upgrade was a non-copyable diagnostic message with an opaque code in it which, as I understand it, is basically the equivalent of "Huh, oops, maybe try again?" and my colleague spent a week trying to uh, share data from a "Sharepoint" table.
But .NET's CLR doesn't seem especially shitty. It's not awesome, I don't feel that RIIR urge when I work with C# and I probably wouldn't with F# either but it's fine, it's like Java again, or maybe Go or Python. It's fine. I don't hate it and that's enough.
F# is a lovable language as in people are really enjoying using it vs not being bothered using it.
Once every other month a new F# link lands on top page and receives a few hundred of upvotes.
I think F# needs and deserves more publicity in order for it to win a larger audience. If only F# community would be half as vocal as Rust community.
Iove the ideas behind functional programming but I never properly learned a functional programming language. I will probably never have the opportunity to use it professionaly and learning it just for hobby doesn't make sense to me.
If I am developing something in my spare time I also like to use something I can earn money with so I can hone and maintain my earning skills. Maybe sounds like min maxing.
If I would be in a situation where I can develop software just out of pleasure or pure curiosity, I would use just whatever language I deem interesting.
I tried F# some years back when I was searching for a language to port my OCaml project in... It felt too much .NET-y and too much MicroSoft-y. And back then .net for linux had just been released and was somewhat unpolished.
It seemed that I had to learn C# in order to use F# properly and it seemed that porting it to C# was the saner option. I went with Rust after all and it seems to have been the right choice.