My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those frameworks feels like old .NET to me. The frameworks themselves weren't designed for a minimal IDE, and language first development initially often assuming dev is in full Visual Studio with GUI XAML editors, EF designers, etc. To be bluntly honest with my opinion it isn't a dev workflow that would fly/got started in other more open languages including F# which should be develop-able and maintainable with a lot less tooling support.

F# feels like a different dev workflow than C#, which IMO is a very good thing in F#'s favor. It feels more like coding JS, Go, etc to me with static typing and richer features. I also think EF, as it is designed, doesn't lean to the FP approach that well.

I personally don't like EF - I'm happy with something in .NET like DbUp for migrations and straight SQL. Normally I get better performance anyway doing this and in the age of microservices I feel this pattern actually makes it easier to change DB's if you need to (but I still assert you probably never will without a rewrite most of the time) - just use the different query language and port your data access layer. Move to Redis? Just port your F# module that queries the DB in SQL to Redis code. In F# it also allows a richer data modelling experience doing it this way (e.g use of DU's for modelling cases in your domain) since db logic is decoupled from your domain types.

I never believed my domain model had to look similar to my DB table design which is what EF typically encourages. Especially with the modern features of DB's like Postgres you are leaving more and more performance on the table. In the apps I've written doing that leads to lower DB performance than otherwise, sometimes for some quite trivial apps.

TL;DR: Tooling like Resharper, designers, etc is nice but often is there IMO because the language itself is bloated and not expressive enough to just state your original intent there succinctly. If the code is enough then F# can express pretty much what C# can.

Languages alone are worthless what matters is the whole development experience.

When F# came out in 2010, it appeared it would be made to share the podium with C#, VB and C++/CLI (even that black swan has better tooling on VS).

Instead what we have witness is that management doesn't really know where to F#, and naturally they cannot take it from the box.

More recently they are positioning to go against Python in data science, when .NET lacks the library ecosystem (ML.NET is still half way there and favours C# anyway), and the Microsoft was able to convince Guido come out of his early requirement with the purpose to improve CPython's performance on the top of the already existing ecosystem.

Meanwhile Intel and NVidia are also on the race to improve Python for GPU compute.

So in the end that leaves F# as a nicer ML derived language that happens to have access to the .NET libraries, with a community that kind of re-invents what .NET already offers, and a master that to this way is wondering what to do with it, other than a laboratory for C# features.