However amusing, this comparison doesn’t seem accurate to me. F# may appear more challenging only to someone who is already accustomed to OO programming languages. For people just starting to code, without pre-existing habits, learning F# could be much easier than learning C#
But knowing to effectively programming F# requires you to understand OOP and the functional abstractions. Most libraries in .Net still target C#, so understanding C# syntax and mentally translating it to F# is often required. If your application doesn't require many outside dependencies that might be different, but for most projects F# will require a lot more learning.
I have been learning F# for a while now, and while the functional side that is pushed heavily is a joy to use, anything that touches the 'outside world' is going to have way more resources for C# as far as libraries, official documentation, general information including tutorials etc. You will need to understand and work with those.
So you really do need to understand C# syntax and semantics. Additionally there are a few concepts that seem the same in each language but have different implementations and are not compatible (async vs tasks, records) so there is additional stuff to know about when mentally translating between C# and F#.
I really want to love F# but keep banging my head against the wall. Elixir while not being typed yet and not being as general purpose at least allows me to be productive with it's outstanding documentation, abundance of tutorials and books on both the core language and domain specific applications. It is also very easy to mentally translate erlang to elixir and vice versa in the very few occasions needed.
Its ironic that the thing that is hard to learn about F# is C#, or more to the point, the patterns/idioms in C# libraries and frameworks. I've seen the same reaction more from people coming from other ecosystems personally working with F#. There's a lot of stuff in C# that people in Java/C# land take for granted that you just don't have to learn in other languages (Javascript, Go, Python, etc) - lots of OOP patterns, frameworks, etc. Staying in the F# lane seems to be easier but can be limiting, but at least you know you won't be stuck if you need an SDK/Library/etc.
The flipside is that adopting F# is less risky as a result - if there isn't a library or you are stuck you can always bridge to these .NET libraries. Its similar I think with other shared runtime languages (e.g. Scala, Kotlin, Clojure, etc). You do need to understand the ecosystem as a whole at some point and how it structures things.
Gleam from a language perspective seems really nice - but it's in it's ramp up stage, I will go through the Gleam Exrercism track and keep an eye on it. It would be great if it became the general purpose typed pragmatic functional language with a large ecosystem I am after!
I've found this when seeing F# team adoption in the past especially if coming from outside the .NET ecosystem (no previous .net knowledge). It is easier learning F# for a number of reasons BUT as per another comment when you need to use the "inter-op feature" (i.e. using C# libs) then the learning curve widens quickly especially if using C# like frameworks - libraries are typically still OK/relatively easy. I see interop to large frameworks and moving to different idiomatic C# styles as an advanced F# topic for these adopters.
While it's good to have the escape hatch; because it means its less of a risk to adopt F# (i.e. you will always have the whole .NET ecosystem at your finger tips) if the C# framework being adopted is complex (e.g. uses a lot of implicits) it requires good mentoring and learning to bridge the gap and usually at this point things like IDE support, mocking, etc that weren't needed as much before are needed heavily (like a typical C# code base). Many C# libraries are not that easy therefore IMO, but with C# native templates, etc it becomes more approachable if coming from that side.
I've found things like the differences in code structure, the introduction of things like patterns (vs F#'s "just functions" ideal), dependency injection, convention based things (ASP.NET is a big framework with lots of convention based programming) and other C# things that F# libraries would rather not have due to complexity is where people stumble. Generally .NET libraries are easy in F# - its frameworks that are very OOP that make people outside the C#/Java/OOP ecosystem pause a bit at least in my experience. There's good articles around libraries vs frameworks in the F# space if I recall illustrating this point.
