[pjmlp]

Mixing languages increases the code complexity and hiring requirements for anyone that has to touch the code.

Everyone on the project has to learn two languages, two ecosystems, because naturally F# folks either reinvent or create idiomatic wrappers for what .NET already offers, a typical side effect in guest languages.

And then there are the enterprise support teams that explicitly only give support if the issues are reproducible with C# when giving example on tickets, increasing the costs to submit support tickets.

[exyi]

Most F# devs know some C# anyway, I don't think this is a big problem. It might be a problem if you mix C# and, IDK, Lua, but C# and F# are just good friends

[pjmlp]

The point was the other way around, how to justify the adoption of F# in Microsoft shops, when Microsoft itself isn't sure where to go with it, doesn't invest in better VS tooling for it, and recently behaves as the C in CLR stands for C# instead of Common.

[throw868788]

I think this is a problem with many languages - e.g. Scala, Kotlin, etc. The easier justification really is: Does it fit your problem space? Will you save dev time overall, is it more maintainable using this tool? Do your staff prefer working with one tool over the other? Does it meet business objectives?

I don't think F# will ever be more than niche; that I can agree with you. Not because of any technical reason though; perception and marketing unfortunately does matter. Your points around "investment", etc are to me impressions/metrics around that.

In the end these things are just tools. I'm personally in a team that is doing a lot of generic math, and in our .NET based projects F# seems easier and quicker to get that performance. I know C# preview adds some improvements here but it seems more complicated than the F# approach.