I understand where you're coming from on these 100%, but I believe some of the conclusions might be more dire than they are in practice.
Both identity and efcore both work fine with F#. What _doesn't_ work is the EF Core design-time support (having models auto-create your schema) and scaffolding razor pages with F# (razor pages just doesn't work in general).
Calling these APIs (authing your users, and interacting with the database) work fine.
I've used mostly database-first design, and tweaked the stock identity pages code anyways so these things haven't affected me a ton (though I _would_ like to use razor pages, since it seems nice and simple for the 80% use-case).
The temptation to whine, cry and complain is too high in developer communities, as always.
It's either "just the way I want it exactly" or "unusable", any smallest and most accessible but slightly different option from preferred way to make things work be damned.
I'm really sad to see a part of F# community being persistently vocal against .NET which makes F# viable and possible in the first place.
I'm happy with how usable F# is as the moment, though it's not hard to sympathize with the sentiments that get thrown around.
F# has had a good run with a lot of open-source efforts in different domains, but as some core parts of the domain evolve (asp.net), if there are changes made which make it more complicated or prohibitive to use F# (t4 templates, roslyn analyzers, custom code-behind behavior), it can seem like F# is on-track to become deprecated by the moving-target that is it's native platform tooling.
I don't have much of a doomer mindset about things, since from the evidence of the F# team's priorities, it's keeping up with CLR and C# specific features (check the F# releases for how many features are compatibility-focused) while also delivering on some very cool F# specific things (SRTP, nested record copy/update, etc).
That's an extremely uncharitable take of my comment. I wouldn't call the many days I've spent investigating and opening issues that the F# community didn't even know about (because it's on life support) to be whining about small things. I can't tell you how many times things just don't work and the community kinda shrugs it off and says "use C#".
If you look in the database section of F# websites, maybe 20% of those libraries work. If you bring it up to people online, they'll say "yeah use Dapper, it's the only thing that works".
This just isn't the case in Clojure and I don't think the expectation is that it should be.
But EFcore and Identity are documented assuming you'll use scaffolding. They set up a bunch of models for you representing users and roles. You wouldn't know how to set this up if you tried to do it in F#. You'd have to set it up in C# first to see what it would look like, and then you might as well just use C#
Agreed on most of this except for the takeaway (seems to be a theme haha).
In the end, I still ended up using F#, since it was only about 30 minutes of copy/pasting the classes/etc over once, and for the rest of the time in development I got to stay in F# land.
To be explicit, I did do what you say here. I scaffolded things out in C#, then just copied/translated that over to F# calls. All the APIs still work just fine.
I'm still a little confused on your answer to this. C# generated a big `BuildTargetModel` method on each generated migration, even if there are no changes. Are you changing this to an F# file every time? On every migration?
Both identity and efcore both work fine with F#. What _doesn't_ work is the EF Core design-time support (having models auto-create your schema) and scaffolding razor pages with F# (razor pages just doesn't work in general).
Calling these APIs (authing your users, and interacting with the database) work fine.
I've used mostly database-first design, and tweaked the stock identity pages code anyways so these things haven't affected me a ton (though I _would_ like to use razor pages, since it seems nice and simple for the 80% use-case).