[dlkmp]

If you had to start over, would you still recommend to yourself to learn F# in 2022?

I am asking this as someone who has dabbled in functional languages (F#/ Haskell) multiple times over the years but, despite liking the elegance of functional code, never reached a level of productivity that came close to what I am used to from imperative languages. Specifically for C#, given the trend of baking more and more of the cool functional stuff into the language (e.g. [1]), I am wondering whether F# still has enough unique features to justify the effort.

[1] see e.g. https://devblogs.microsoft.com/dotnet/early-peek-at-csharp-1...

[shirogane86x]

As a former F# full-time dev, I'd say that there's a few things that really make it worth to use F# (and I will still use it instead of C#, where there's a possibility, in the future):

- Computation expressions make it possible to do ergonomically use value based error and nil handling, with option and result (very awkward to do in C#).

- type providers are a way to generate types at compile time based on some input. They let you do amazing stuff, like compile-time checking SQL against a specific database and automatically generating the correct types for inputs and outputs, or automatically generating types for stuff like XML or JSON files, based on a sample.

- really good type inference and (in my opinion) a better type system than C#'s, mostly wrt generics. You reap all the benefits of static typing, while also typing very very few types, and you get to express some things that just aren't unfeasible to express safely in C#. For example, the compiler will infer things like:

    let add a b = a + b * b
    //has type
    ^a -> ^c -> ^d
    when (^a or ^b) : (static member ( + ) : ^a * ^b -> ^d) and
    (^a or ^c) : (static member ( * ) : ^a * ^c -> ^b)
    //which means: a function from 'a' and 'c' to 'd', where either 'a' or 'b' has an add operator, and either 'a' or 'c' has a multiplication operator

you could also explicitly type it out as a type signature, by the way.

there's probably more, but these are the things that came to my head. DISCLAIMER: I usually reach for F# anyway, as I feel a lot more comfortable programming functionally compared to imperatively. F# is the only real option for actual FP on the CLR - so I'm a bit biased (and for much of the same reason, I would rather use Scala compared to Java on the JVM, for example). My actual favourite programming language to use is Haskell, so take that as you will :)

[occamrazor]

Shouldn’t the type constraint on multiplication be existence of an operator:

    (*) : ^c * ^c -> ^b ?

[WorldMaker]

> If you had to start over, would you still recommend to yourself to learn F# in 2022?

Learn it, absolutely. A lot of comments here are arguing "maybe don't use it in Production", but I think it's a clear case that it is still worth learning even if you aren't "using".

Even though C# keeps adding a lot of F#-inspired features, there's still (and likely will always be) a large gap in the "native" idioms and the cultural best practices. There's still some big differences in encountering the "F#-like" stuff in the imperative wilds of C# than in the tame functional fields of F#. Learning those same tools in the "safer environment" where they feel more natural, learning the idioms that make them truly powerful in F# unlocks ways to think about these tools, that even if you aren't using them day to day in F# and are just applying them to C#'s relatives can still be very useful ways to think.

(A lot of what this article here talks about has a different perspective from F# and especially Haskell where "Lazy evaluation" is a much, more natural way of working than the imperative mindset of "every line does a thing immediately", which is what imperative means.)

Coincidentally, I've made several recommendations in recent PRs that developers take some time in F# lately. I really do strongly believe that learning it makes for better C# programmers in 2022, especially because of all the F# tools now in the language. It's too easy to fall into mental traps you don't even know might exist in LINQ and records and async/await and AsyncEnumerable and ReactiveX and so forth, with the list still growing, without the education of languages like F#. Even if the other comments can give you a lot of reasons why you maybe shouldn't push to use F# in Production, it's still an incredibly useful educational tool at least.

[Eji1700]

Absolutely. I'd probably recommend it earlier, but i also have a somewhat unique work environment. It's a very small team and we have somewhat nonstandard goals. I can't comment on how it'd work on a 50 man team or whatever on a larger project.

That said, I think F#'s beauty comes from how much easier it is to model your code, find errors in compile, and easily restructure once you really get the hang of doing proper design and passing functions. The few runtime errors that occur are pretty trivial to debug as well thanks to immutable by default.

It DOES require a major shift in how you approach your problems if you've been coding with something like C# for a long time, and that can take awhile. The tutorials are not great (often assume you're coming from something else), and the unfortunate mix of library support with awkward issues (you can use specter console, but if you follow the docs you'll hate your life) is brutal on adoption.

I do sincerely believe it's basically this diamond being totally ignored though because "well i'll just use C#" is a fair thing to say when at the end of the day we've all got shit to get done and the library docs are for that.

Learning F# though has made me a vastly better coder and I think it's EXTREMELY elegant in how it enforces good practices and lays out its code. It doesn't have all the advantages of something like haskell which is a shame (Higher kinded types and generic lens syntax for records would be AMAZING), but it also doesn't force you to learn monads to print to the screen.

Being able to jump back and forth between styles as needed is VERY powerful, and you don't have to worry about having sideeffects in your first mockup. And once you REALLY get it, having super light and easy syntax for passing functions around lets you do some CRAZY abstraction on your program logic that makes down the line adjustments/additions trivial and intuitive.

This comes from someone who spent nearly a year being TERRIBLE at the language. In part because the onboarding was even worse when i started (worse tutorials, lots of stuff referencing no longer working framework libraries, weird VS Code bugs that made things harder than it should be, me just not being very good at this stuff).

I think that the biggest shame is that F# almost never makes libraries because "Oh there's a dotnet one already", and while you TECHNICALLY can just use it, you quickly can wind up missing out on the neat features that brought you to F#, until you really learn how to easily swap between styles so you can invoke whatever features you want, and then get them back in idiomatic F# and start shoving around your functions.

[zihotki]

My experience says that no, unless you're in a team of F#-minded people. There are some companies like that but it's quite rare.

And the main challenge is that C# is good enough and nobody wants to switch over. As soon as F# evangelist leaves the team, all F# code slowly becomes obsolete and at some time rewritten in C#.

[Akronymus]

> If you had to start over, would you still recommend to yourself to learn F# in 2022?

Not GP, but I'd do it even for just the interactive shell on the .net ecosystem.