4 ms·

I don't even care about the runtime, imagine if F# devs made anything that wasn't on top of Asp.net. The small community coupled with breaking changes from Asp.

I don't even care about the runtime, imagine if F# devs made anything that wasn't on top of Asp.net. The small community coupled with breaking changes from Asp.net leads to a lot of issues, and the interop story of F#/C# and Clojure/Java is night and day I like Asp.net, but the thing I've run into several times in F# is there are breaking changes in libraries that the developers of F# can't keep up with. - Giraffe doesn't support swagger docs, you have to use Asp.net directly, because the swagger generation isn't compatible with the way Giraffe does routing - Microsoft Identity uses EF core by default. The EFcore.FSharp library doesn't support past .NET 6. You could use your own backend, but at this point, it's easier to just use C# interop You could use C# for the routing of your app and F# for the business logic. But then there's the C#/F# interop story. Lots of little finicky type differences you have to convert. Whereas using Java from Clojure feels easy and natural to me. And even if you use Asp.net directly and do interop correctly, you're basically using C# at that point. You're missing a lot of benefits of a functional language. It's not worth it in my opinion, even though F# is a wonderful language to me. It's tough to learn the ecosystem in Clojure. But once you do, I've found the "small libraries" approach much better than the whole ecosystem tying itself to one web framework it can't even keep up with.

throw868788 3y ago
Its funny because I've found the opposite; the fact that the smaller community (and lets face it - most FP langs have a much smaller community than needed to get the scale you are after) the more it needs to piggy back on the army of engineers in the mainstream language target and stick to only its value add as a technology. There were web frameworks in F# that were written from scratch, but fundamentally ASP.NET is quite good and fast enough at least from my evaluations and these frameworks are now out of favor. I personally don't have much issues using ASP.NET directly from F# (don't bother with Giraffe or anything like that); its not too hard. The routing layer is only a few classes/functions anyway - it isn't the majority of your program. I guess maybe I'm in a different position to you - I find for the few bits of ASP.NET config it isn't worth switching to C#. A few rules you need to follow but I would say that is a lot less than the Clojure learning curve and you get static typing still - that is just my opinion however. My experience is that both languages have their pros/cons and tbh both have their challenges w.r.t adoption. My personal view is most of these challenges are not technical. The issues we complain about with the language as developers are IMO minor (i.e. things are still possible or decent compared to some other languages) and probably aren't the major factor in the wide scale technology choice away from FP in general. For better or worse developers are often "languages takers" not "language deciders" in most big shops and this is where most of the jobs are - its only in niche elements/problem spaces (i.e small shops, dedicated niche teams, etc) where niche technologies can be worth it. This means not a lot of jobs; but when there is a job it can be higher paying. Big employers drive the market for technologies though when it comes to large scale usage and they want commodity fungible developers (i.e. resources), and are happy using a mediocre tech that gets the job done to do it. Unless there is a "killer app" where the language must be used to unlock the value most managements will stay clear of better tech - predictable, boring, commodity tech that I can get anyone in for (contractor, offshore person, etc) wins for them every time especially for the MBA/product manager/etc types. In the current economic climate developers are trying to meet the jobs that are being advertised as well (higher interest rates, less startup's, etc etc).
- Capricorn2481 3y ago
  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.
  - neonsunset 3y 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 https://github.com/efcore/EFCore.FSharp/pull/162
  - banashark 3y 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).
    - neonsunset 3y 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.
pjmlp 3y ago
What you describe is a very good example, why I seldom rely on guest languages for production code. Communities can't control themselves, always try to create an ecosystem on top of the ecosystem, some of them even are quite vocal against the platform that made their beloved language possible in first places. Thus as the platform moves under their feet, everyone fails to keep up, to make anything usable one has to master now two stacks instead of one, and spend even more time tracking down issues. Clojure's approach to embrace the host is a much better way to handle this.
fire_lake 3y ago
Suave does not depend on Asp.net

throw868788 3y ago

Its funny because I've found the opposite; the fact that the smaller community (and lets face it - most FP langs have a much smaller community than needed to get the scale you are after) the more it needs to piggy back on the army of engineers in the mainstream language target and stick to only its value add as a technology. There were web frameworks in F# that were written from scratch, but fundamentally ASP.NET is quite good and fast enough at least from my evaluations and these frameworks are now out of favor. I personally don't have much issues using ASP.NET directly from F# (don't bother with Giraffe or anything like that); its not too hard. The routing layer is only a few classes/functions anyway - it isn't the majority of your program. I guess maybe I'm in a different position to you - I find for the few bits of ASP.NET config it isn't worth switching to C#. A few rules you need to follow but I would say that is a lot less than the Clojure learning curve and you get static typing still - that is just my opinion however. My experience is that both languages have their pros/cons and tbh both have their challenges w.r.t adoption. My personal view is most of these challenges are not technical. The issues we complain about with the language as developers are IMO minor (i.e. things are still possible or decent compared to some other languages) and probably aren't the major factor in the wide scale technology choice away from FP in general. For better or worse developers are often "languages takers" not "language deciders" in most big shops and this is where most of the jobs are - its only in niche elements/problem spaces (i.e small shops, dedicated niche teams, etc) where niche technologies can be worth it. This means not a lot of jobs; but when there is a job it can be higher paying. Big employers drive the market for technologies though when it comes to large scale usage and they want commodity fungible developers (i.e. resources), and are happy using a mediocre tech that gets the job done to do it. Unless there is a "killer app" where the language must be used to unlock the value most managements will stay clear of better tech - predictable, boring, commodity tech that I can get anyone in for (contractor, offshore person, etc) wins for them every time especially for the MBA/product manager/etc types. In the current economic climate developers are trying to meet the jobs that are being advertised as well (higher interest rates, less startup's, etc etc).

Capricorn2481 3y ago
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.
- neonsunset 3y 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 https://github.com/efcore/EFCore.FSharp/pull/162
- banashark 3y 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).
  - neonsunset 3y 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.

pjmlp 3y ago

What you describe is a very good example, why I seldom rely on guest languages for production code. Communities can't control themselves, always try to create an ecosystem on top of the ecosystem, some of them even are quite vocal against the platform that made their beloved language possible in first places. Thus as the platform moves under their feet, everyone fails to keep up, to make anything usable one has to master now two stacks instead of one, and spend even more time tracking down issues. Clojure's approach to embrace the host is a much better way to handle this.

fire_lake 3y ago

Suave does not depend on Asp.net