Community-led tooling for F# in Visual Studio

I really, really like the F# language, but the tooling is so bad (compared to C#) that it's a real struggle to continue to justify using it. I admire the effort put in to F# Power Tools development (I've been using it for a long time and is currently on 2.0), but TBH it's like a slow, buggy implementation of a quarter of the C# tooling. Don't get me wrong, the effort is commendable and I know you're not supposed to criticize OS projects unless you're involved yourself, but from a practical day-to-day point of view, it's not working well.

The demos that Tomas Petricek and others in the community do are nice, but in real-world applications of even moderate complexity you almost invariably run into impedance mismatches and annoyances.

I'm currently working on a F# backend for a service with a WebAPI 2 front-end.

- We had to create a C# glue project to be able to publish it as a web app on Azure. This works, but dependency tracking across language barriers in .Net is flaky, so we have to remember to add all Nuget packages to the glue project manually, or we get run time errors in production (not during compilation or locally in test, but in production) as the assemblies are not published.

- Go to definition does not work across language barriers, even when the projects are in the same solution. So you're in F# code, place the cursor on a data tyope defined in a c# file and press F12 to navigate to the source and you get an F# view of the data structure, instead of going to the source.

- The async models are famously different between F# and C#, so you have to marshall back and forth between them, resulting in a lot of `|> Async.StartAsTask` and `Async.AwaitTask` in the F# code, and don't get me started on how to convert an f# async computation to a .Net Task in C#. Pretty, it aint.

- While you can easily create WepAPI controllers in F#, there are basic things that you just can not do. One that bit me recently: having optional query string parameters. Super easy in C#, impossible in F#. Ended up writing a C# controller just for the endpoints that require this, so now I have controllers in the same API surface written in two languages.

Neither of these things are the end of the world, but they do add up, so for me personally it is not a given that I will use F# for my next project.

Yup, it's a bit unfortunate, but that's how it is most of the time.

I found myself using F# for core libraries with clearly defined boundaries between APIs and assemblies - IMO that's where the language shines right now. You can have your core logic contained in a library with a separate, C#-compatible API.

Using F# for WPF, ASP.NET MVC or ASP.NET WebAPI development wasn't quite as stellar experience, also because of the state of the tooling. I'm even wary about type providers, when they work - it's great, when they don't - you're pretty much screwed with no real recourse. In case of relational DB access, most .NET libraries (both full-ORMs and micro-ORMs) are C#-oriented.

Therefore, after including all the annoyances you listed, it's hard to justify anything more than 'handle core libraries in F# with C#-compatible API, do the rest in C# - it's good enough' to the business...

Like when does it make sense to have a business representation of your data in a language like F#? I'd say as soon as you want the full expressive power and safety of records and discriminated unions. Our domain representation was substantially different from what would easily fit in a relational database, so we start with it from the beginning.

In C#, I think ORM classes have a lot going on, so I prefer to use them only for converting to a data structure.