Just use F# instead and you will have Rust, typescript, Javascript, dart, python all at once
https://twitter.com/FableCompiler/status/1550429007443017729...
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.
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.
Where it is pretty much DYI.
And see above for database, Type Providers are great at least for SQL server, I think the sql one also works for PostGres but I never used it so not certain.
GUI is a mess last I knew though I agree.
What I care about are the code generation libraries that get served alongside NuGet packages with attributes, e.g. the ones used by MVVM, MAUI or Blazor.
- 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.
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.
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.
You can bind them to code attributes, no more INotifyProperty by hand or by having common base classes.