Anecdotally, the handful of people I've known that worked in commercial Haskell shops, after the initial honeymoon period intensified by actually finding a paying Haskell dev job, wishes they were using a more practical "happy medium" FP language. I don't know anyone that's used F# in production, but nobody I know that's worked in Elixir, erlang, or elm environments has expressed the same frustration.
As someone who has used F# in production at least in my experience running teams that do (on some very large products generating significant value to be vague about it) teams don't want to stop using it once they get over the initial hump. It's almost the opposite - they express frustration when they are required to jump to a more mainstream language. "Why when we have no issues and can do everything we want" is feedback I have received.
My opinion: If F# was on any other platform than .NET it would be a widely adopted language - the problems are cultural not technical/capability based. Not because .NET as a platform is bad technically (its gotten quite good and cross platform), but the culture in that space (typically enterprise dev shops) isn't really one of trying new things for marginal benefit - There's safety in the C# herd. There's also seems to be a reluctance for certain regions/areas (e.g. SV) to adopt .NET in general - culturally they are probably the regions more likely to adopt more niche languages and try new tech as well.
I don't think there is pressure to move F# teams off to C#. It's probably unheard of, but there is also a fact that few companies use it.
The bigger problem is that F# is even more affected by a problem that .NET suffers from in general, through no fault of its own: there is a degree of bias in the industry against .NET outside of its ecosystem (and even within it, some just skill to appreciate the tools they have) so perfectly capable and performant applications, the teams that own them are sometimes pushed to migrate to Go/TypeScript/even Java - all of which constitute a significant and equally frustrating downgrade. The most recent big example of that is Walmart forcing all ex-Jet.com teams to rewrite their F# codebase in Java, where the latter just faced with lack of understanding from Walmart's architects what their stack can even do or what it is.
Another factor is F# sometimes pushes just ever so slightly over the budget for "unconventional" - it's different enough from C-family of languages that it takes some getting used to, and has a learning curve. This combined with the fact that C# itself is very flexible and has been leaning into its functional side for a long time put F# in an awkward spot - it's not the kind of upgrade to C# that Scala or even Kotlin are to Java.
I think what will help F# is the growth of .NET adoption in the industry itself - it's just hands down better offering than most of the competition by sheer existence of ASP.NET Core and EF Core alone in the business domain, and is also a straightforward and fairly open core kind of an ecosystem - companies that use F# would likely find it much easier to contribute to F# itself or .NET runtime than companies that use Scala or Elixir or what have you. In a way, it really is just a marketing issue.
> " don't think there is pressure to move F# teams off to C#."
To clarify I didn't say the move was to C# specifically. What I meant was another tech stack often in a different problem space (e.g. frontend with Typescript, scripting with Python, etc) the staff just say F# does it for what we need as well. I agree with your point however - if you are in the F# space already and your staff are already familiar with it there's little reason to move to C# since they have the same ecosystem anyway expect maybe for some edge cases and generated code projects.
Interesting. I wonder where you met them. I've worked with tens of Haskell programmers in my career, most of whom were sad if they were required to stop working in Haskell. I've never met anyone who actively sought out a Haskell job and then subsequently wanted to stop working in Haskell.
Many of my colleagues would describe themselves as taking pay cuts to write Haskell provisioned with Nix with type-safe interop with Ruby and our frontend. If you're into it, you're into it. And it has the effect of putting absolute mutants on your team.
