undefined | Better HN

0 pointsCapricorn24811y ago0 comments

For me it's not that using Asp.net from F# is bad, but the little things that add up.

Like I said, if you want to use Microsoft Identity, you need to either write your own backend that doesn't use EFcore or use .NET 6 instead of 8. Why? EFcore is essentially a scaffolding library. You can't use it from F# without EFcore.FSharp. EFCore.FSharp doesn't support anything higher than .NET 6.

So now we have a scenario where the main auth library in asp.net doesn't work in F#. I've never had these issues in Clojure where I just flat out can't use a Java library.

0 comments

banashark1y ago

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).

neonsunset1y ago

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.

banashark1y ago

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).

Capricorn2481OP1y ago

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.

Capricorn2481OP1y ago

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#

banashark1y ago

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.

2 more replies

neonsunset1y ago

Have you looked into whether the maintainers of EFCore.FSharp look for assistance?

It seems there is work in progress on bringing .NET 8 support here https://github.com/efcore/EFCore.FSharp/pull/162

j / k navigate · click thread line to collapse

0 comments

banashark1y ago

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.

Calling these APIs (authing your users, and interacting with the database) work fine.

neonsunset1y ago

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.

banashark1y ago

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.

Capricorn2481OP1y ago

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.

Capricorn2481OP1y ago

banashark1y ago

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.

2 more replies

neonsunset1y ago

Have you looked into whether the maintainers of EFCore.FSharp look for assistance?

It seems there is work in progress on bringing .NET 8 support here https://github.com/efcore/EFCore.FSharp/pull/162

j / k navigate · click thread line to collapse