Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that would of never approached C#. I agree that each language has its sweet spot. Looking at their feature sets I think:

- Domain modelling, algorithm, business logic, etc is easier with F# in general. C# is getting better than this, but F# is there and has been there for a long time.

- Integrating with build tooling and generation tends to be C# because these tools were designed for that target (i.e not the language itself). The value is in the tooling and the engineering in that - C# just happens to be the target.

Personally with the above I've found most of the logic tends to be in F# with some C# projects for where the packages needs that build tooling support (i.e. not the language or syntax, but for the tooling or other features of Roslyn). An example would be Grpc.Tools. Most of the time these projects can use generated code anyway so the writing of C# can be kept to a minimum - i.e. not one single C# file in the C# project. Besides I think the learning curve/barrier for a language isn't really syntax, or language features - its the libraries to use, the patterns, the ecosystem, package manager, CI/CD settings, etc. Using F# isn't a large cost once you've learnt all those things that are shared which is way more than isn't.

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.

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

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.

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.