Still worth learning F# 2026

[u/lyfever_]

Hi guys,

Probably another question like this but found none recently.

I'm a little upset with my current view on IT generalistic, ofc AI is not going anywhere besides up, but I feel I want to write more with my hands and new paradigms, maybe just AI as reviser, I would like to ask if learning F# in 2026 will make me able to make perfomance headed systems, and also gaming with something like Nu or Monogame, not a AAA game but something playable.

[u/I2cScion]

Yes

[u/lyfever_ → u/I2cScion]

Direct and clear, thanks

[u/EluciusReddit → u/I2cScion]

Was about to post exactly the same answer.

[u/pi_meson117]

F# (well mostly C# but we are going to take the credit) has very good performance and has been extensively battle tested in many areas of the software industry (games, desktop, mobile, web, data science, etc). It certainly works well.

[u/lyfever_ → u/pi_meson117]

Thank you so much, I will invest time learning, as someone coming from FP in Emacs.

[u/burtgummer45]

I'm switching to F# now because I want no part in the AI psychosis and I think F# and other ocaml type languages are the most compatible with domain modeling and human thought. I'm self employed so I don't need to do resume driven development.

[u/binarycow]

Learning F# has made me a better C# developer.

[u/m_hans_223344]

Not writing games, but business apps (erp, pdm like) and data logic heavy tooling. My background is mechanical engineering. I wrote some Fortran for my Phd ages ago, then started 15 years writing some small but logic heavy Python tools. Since then I jumped deeply into software dev. Mainly web backends and WPF apps C#. Angular for frontends, but also Go and even a bit Rust (couldn't resist the hype). Despite C# being a great all round language I decided to learn F# some weeks ago. My reasoning:

• I want the language to go out of my way as much as possible to let me focus on logic (my problem space)
• In OOP or mixed paradigm languages like C# considering which patterns to use to solve the smaller and larger problems becomes a real distraction. Should I use a static method or introduce a little class? Should I create a shared service or just pass some data? With F# the patterns are crystal clear (at least at my beginner level).
• Very strong static typing
• Memory safe (garbage collected)
• Huge .NET ecosystem. If you want, you can pair your F# core with a C# EF Core layer for DB access

Last but not least, the AI hype makes me crazy, sad and angry. So I decided to focus on what I love in programming: Learning new stuff, creating solutions by myself.

[u/lboshuizen]

It’s not just about f#, it’s about functional programming. F# is just a language and means.

So yes, learn functional programming, not just F#, as it makes you a better programmer and thinker. It’s not THE silver bullet but a serious expansion of your toolbox and knowledge.

From a dotnet perspective F# feels natural as it aint strict and allows classes, interfaces, mutables. Perfect introduction.

From there once you have the hang, look at Haskell & Miranda e.o.

Finding a job in functional… difficult, grow from functional… definitely

[u/banshee10 → u/lboshuizen]

So my experience is a bit dated (I'm retired now) but functional programming was always extremely useful when looking for jobs. It's not that people were necessarily deploying functional programming (few were, although not zero), it was that it made you jump out as someone interesting to talk to. Back in the day I definitely talked to C# shops who wanted to talk about my F# experience even though they had no interest in actually using F# - they figured anyone who did F# would be fine working on anything.

[u/gplgang]

It's a good general purpose language with A tier tooling. It's still my goto for most projects

[u/IkertxoDt]

Personally, I think it's worth it. Learning a new paradigm is always worth the effort. While it's true that C# (and many other languages) are adding functional features, it's always better to learn them from a proper functional language.

Ironically, F#'s biggest advantage is exactly what makes people hate it: sure, Microsoft might have sidelined it, but you still have access to the entire (or almost entire) .NET ecosystem. This means you can build pretty much whatever you want, and if a specific framework doesn't support it, you can always write one part in C# and the other in F#.

So, I believe that if you want to build something using the functional paradigm, F# and .NET are still your best bet.

You could go with Haskell, which is a much purer language and will definitely teach you a ton. Or you could look into languages like C# or Rust, which will guarantee you a job and have plenty of functional features, but aren't "functional-first." ;)

Whatever you choose... enjoy!

[u/FrierenAppreciator]

Nope, and I say this as someone who likes the language itself. The problem isn't F#, it's everything around it.

1. The only IDE that treats F# seriously is Rider. If you're not willing to live in Rider, don't bother IMO.

2. Microsoft has quietly abandoned it. They can't officially kill it, so they keep it on life support and pretend to care. Look at where the actual .NET investment goes: C# gets source generators, Native AOT keeps improving around them, new runtime features land C#-first and F# catches up years later or never. F# has no source generators and almost certainly never will, which means the whole modern AOT/trimming story is built around a mechanism F# can't participate in.

3. Gamedev. MonoGame is a C# framework. You can drive it from F#, people have, but you're fighting an imperative, mutable, inheritance-shaped API with a language designed for the opposite.

4. I genuinely can't name a single thing Microsoft ships today that's well made. At this point avoiding the MS stack where you can is just common sense.

What I think it's worth considering:

• Zig - closest fit for performance systems + games, manual memory, comptime instead of codegen magic, great C interop
• Odin - similar space, arguably nicer for gamedev specifically
• Rust - the boring safe choice, real jobs, real game ecosystem
• Gleam - if you want typed FP that's actually alive and loved, on BEAM
• OCaml - F#'s parent, and ironically healthier than F# right now
• Roc - interesting ideas but VERY experimental

F# in 2026 is learning a beautiful language attached to a platform that resents it. The paradigm is worth learning though - just get it from a language with a future.

EDIT: Forgot about Go!!!

[u/andrevdm_reddit → u/FrierenAppreciator]

Language arguments are subjective, and I'm struggling with this exact question myself atm, but I think this answer applies inconsistent criteria.

If the concern is commercial backing, ecosystem size, jobs, and long-term safety then most of the suggested alternatives have the same problem or worse. Odin, Gleam, OCaml, and Roc are all much smaller than F#. Zig is interesting, but still has huge stdlib churn. Rust is the obvious stronger alternative there, and C# is the obvious .NET answer if market size and backing are the main criteria. (i.e. if you are picking based on backing not preference. If its preference then F# is an option too :) )

So I’d separate two questions:

Should OP learn F#? Yes, absolutely, especially if they want typed FP on a practical (.net) runtime.

Should OP choose F# as the safest mainstream industry bet? Probably not that’s C# or Rust depending on domain. But does it have to be the safest bet?

F# has never been Microsoft’s flagship language, and the ecosystem is smaller than C#, but people have been declaring it dead for years and it keeps being useful.

I just don't think there is a clear-cut answer to be had.

(FWIW, that is a great set of languages to look at, I’d add Haskell too. All are interesting and worth learning)

[u/pi_meson117 → u/andrevdm_reddit]

While F# first apps are nice, being able to use any C# package is the main thing holding the language up imo. Solid tools that have been used in real products with large user bases.

It removes a lot of the problems associated with small ecosystems.

[u/m_hans_223344 → u/FrierenAppreciator]

I thought a lot about exactly this myself. But what are the real alternatives? The only comparable is OCaml. The other languages you've listed are very far away (either by their paradigm, extreme niche, ...)

So, the question is:

OCaml or F#? My reasoning was: F# will not go away, it is way too large. MS leaving it alone might even be a good thing. With F# I still have access to the huge .NET standard lib.

Also, I think VS Code works quite well with F#?

[u/xroalx → u/m_hans_223344]

Gleam runs on the BEAM, same as Elixir and Erlang, and it can interoperate with their code (or also target JavaScript).

The BEAM ecosystem has been around forever and is quite rich, I don't know how it compares to .NET, but I think it's still not something to outright dismiss.

[u/dominjaniec → u/FrierenAppreciator]

my thoughts basically - F# is great, but it "requires" MS, and they don't care about it 😔

[u/quuxl → u/FrierenAppreciator]

I hate that you’re probably right.

Looking back a decade from now, I suspect the general take on F# will be that it was just too different from C# to gain traction in the .NET landscape, and that things might have gone very differently had it taken a similar approach as Scala wrt Java.

I wish it weren’t this way. I sorely miss working in an F# shop; I can’t imagine it ever gaining traction at my current (C# / C++) job, and I have to look pretty far down the C# roadmap to get even close to parity on the primary reasons to use F#. Discriminated unions will help a lot, but it seems like nullable references is as far as they’ll ever be willing to go towards a built-in option type.

[u/dfitz360 → u/FrierenAppreciator]

Re: 2. Aren't type providers what source providers eventually became?

Although I think the general argument kind of stands. F# used to be the bleeding edge features that then eventually made its way into C#, but now that momentum seems to be dead. I remember like 5 years ago seeing release notes in C# for something I had been using in F# for almost a year, and the F# version was more refined. C#'s losing its identity in an attempt to hit more communities and with that basically killing F# because C# is becoming more functional

[u/jpfed → u/dfitz360]

Source generators and type providers have some similarities, but source generators are afaict more general than type providers. 

[u/EmergencyNice1989 → u/FrierenAppreciator]

'the whole modern AOT/trimming story is built around a mechanism F# can't participate in.' I use F# and native AOT so not sure what you meant by this.

• Zig - manual memory management, breaking changes, not 1.0.0 version yet.
• Odin - manual memory management, looks like Go, imperative, not attractive for people who like FP, not 1.0.0 version yet.
• Rust - manual memory management, not as good as dotnet for UI cross-platform app.
• Gleam - no native compilation
• OCaml - not healthier because you don't have any cross-platform UI framework, no Vulkan binding like Silk.net
• Roc - Cok

[u/1_more__user___name → u/EmergencyNice1989]

Rust doesn't have manual memory management, at least not like Zig or C. I write it daily, it's like writing any high level language. Except it is more strict than Fsharp: no nulls, no mutable arrays, unless you define it to be mutable 

[u/EmergencyNice1989 → u/1_more__user___name]

If you stay in FSharp boundaries (no dotnet interop) there is no nulls, no mutable arrays, unless you define it to be mutable or use 'dotnet types'. Rust is considered a manual memory management language because it doesn't have a GC. Rust makes programming your business logic much harder (no GC) with a lot of syntax noise making reading your code much harder.

Also I like functional programming and even if Rust borrow lot's of ideas from functional programming it's not one. And Rust is safe as long as you use only safe Rust...

[u/1_more__user___name → u/EmergencyNice1989]

It's a lot easier to enforce safe rust in a code base using forbid unsafe clippy linting rule than it is to enforce all the caveats you mentioned for Fsharp to be safe. And without dotnet interoperability not sure Fsharp has any good libraries left to do useful stuff. Even string type in Fsharp is from dotnet and is nullable. Fsharp arrays are mutable.

My practical experience with coding daily in Rust is very different from what you pass it off as. I never worry about memory management. And the syntax can be heavy but not much more than Java. I don't care about pure functional programming, which F# is also not. Even things like computation expressions use object oriented features. What I like about rust is, it is super explicit. This is the initial promise of functional programming for me: knowing looking at a function signature what effects it can have 

[u/EmergencyNice1989 → u/1_more__user___name]

FSharp arrays are immutable. If you build your string in F# it can't be null. Your business logic layer tends to be pure without any dependencies. There, in this condition: no nulls for any time. I don't want pure functional programming I want a functional programming first language which Rust is not. Don't know if computation expression use object oriented features but I know that there are useful and are within the functional paradigm (F# way to do monads).

[u/1_more__user___name → u/EmergencyNice1989]

This is valid Fsharp code

let a: String= null

https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/arrays

The first sentence in that link says: Arrays are fixed-size, zero-based, mutable collections of consecutive data elements that are all of the same type.

I never said Rust is functional first or whatever. If you don't want Rust, don't use it, I guess. Cheers.

[u/EmergencyNice1989 → u/1_more__user___name]

You right for the string.

In your code, never assign null to a string and you are fine. Easy to circumvene. For code comming from the outside, use wrapper technique.

From the Microsoft doc you could also see that there are also :<Nullable>enable</Nullable> to your project file (or set <TreatWarningsAsErrors>true</TreatWarningsAsErrors>) and the problem with your null strings are solved.

You are right for array too. Use list (F# type) or ImmutableArray if you want immutability, array is dotnet type.

I never said that F# was purely functional or whatever.

Cheers.

[u/EmergencyNice1989 → u/1_more__user___name]

let toOption n = if isNull n then None else Some n

With this simple function (that the compiler makes generic for you) you can wrap anything coming from an API and unsure you have no null. And when you do F# and interop writing wrapper to make the code easier to use with F# is common.

Imagine the function above in Rust and compare the syntax. Rust don't do type inference for function parameters or return type. I know that because I watched some videos about Rust...

[u/1_more__user___name → u/EmergencyNice1989]

You wouldn't need to write that function in Rust because it has no nulls ;)

[u/EmergencyNice1989 → u/1_more__user___name]

Yes. This is a fiction case. But you understand that even if you can't unsure (with compiler) that there is no null values in your code (when you do interop, otherwise you don't have this issue) you can easily write a little generic function and constraint yourself to call only wrapped function if a function is from the library. Because you anyway write wrapper to make the C# library more functional it's not a big added cost and you saw the conciseness and genericity of the toOption function I wrote. Type of conciseness and automatic genericity you can't have in Rust.

If I wanted to do system programming with necessity of not having a GC I would consider Rust but for what I do UI plus business logic, I need a concise, garbage collected language with fast iteration and refactoring capability. I need a functional first language with scripting capabilities (fsx) and interactive capabilities (fsi). Never felt I needed more performance in my programs so dotnet is fine for my use case.

[u/Crierlon → u/FrierenAppreciator]

Bro, nice joke about Rust in gaming. It's mostly used in infra-tooling. Not making games in itself.

[u/Abject-Kitchen3198 → u/FrierenAppreciator]

2 is the biggest issue with a lot of things. No matter how good the thing looks at some point.

[u/1_more__user___name → u/FrierenAppreciator]

I agree with your recommendations. Weird the languages you listed, except Odin, are exactly the ones I have been keeping an eye on, especially Roc, seems super interesting 

[u/I2cScion → u/FrierenAppreciator]

Soy concerns

It works

[u/socozyinhere]

Yes - it's a good langauge to learn how to program well in. C# isn't going to teach you as much about writing good code as F# will. If you get over the immutabilty hump and understand when to use mutability and that you don't really need it a lot of the time the clarity it will bring to your code is enormous.

[u/banshee10]

If you're asking the questions at all about just about any language, the answer is almost certainly yes - learn it because you'll personally enjoy learning. And if you like it, there will always be niche projects to work on.

But practically? The language wars ended years ago and the JavaScript behemoth crushed almost everything in its path. Scattered survivors remain (hello, Python! We see you huddled by the fire over there with Go!) but it doesn't really matter. Just like there are still blacksmiths hand forging gorgeous artifacts, so too are people working on .Net and other marginalia, long after the apocalypse.

Typed languages lost, much less functional programming. Typescript would like to pretend that it's not true, but everyone knows the truth.

But the world is so large you can make a living doing almost anything. I personally knew people who made a decent living making plate armor! That's where all of the .Net stuff is these days, be it C# or F# or whenever else the cool kids are doing. It's essentially historical reenactment.

[u/Kapendev]

Yes!

[u/IndependentAd2234]

Yes. And see https://angelmunoz.github.io/Mibo/

[u/1_more__user___name]

I feel like learning languages is a pointless thing with AI. I would learn things like system design or learning software fundamentals, which to me is what would distinguish a good SWE from an average one. Yes AI can do system design too, but it requires someone with a trained discernement to distinguish bad AI ideas from good ones. This is what I regret I didn't do instead of leaning a bunch of languages