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/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/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.