Funny, I did exactly the opposite! I really enjoyed f#'s functional-style web framework Suave, but put it on top of services written in OO style, which all used immutable f# records and lists under the hood. It ended up being a lot easier to do all this in f# than mix the two languages, since f# is dual purpose. I called it sandwich-oriented programming.
Using a framework like Suave probably reduces the "impedance mismatch" between ASP.NET and F#. If I had used that, I probably wouldn't have needed to split the code base into C# and F# parts.
I’ve tried to use “ASP.NET Core with F# underneath” for several projects, thinking it would make for an easier bridge for the rest of the team members who were very comfortable with asp.net already.
And each time, it turned out to be a mistake.
Things went way more smoothly by just using an F#-native web framework like Falco or Suave or Giraffe or …
Surely C# qualifies more as "multi-purpose" than F# does? It's certainly more of a multi-paradigm language - my own C# code freely mixes functional, imperative and OO- style (multiple implementations of the same interface etc.) techniques, the latter two of which I struggle to envision being improved by rewriting in F#.
Yes, but from what I've seen, many OO patterns in F# are actually a good deal more verbose than they are in C# (whereas the reverse is true for functional patterns). And writing procedural/imperative-style logic in F# feels like it's fighting against what the language was designed for.
Don Syme makes a distinction between OOP and "object programming" various places on the internet. Object programming is quite natural in F#; possibly even moreso than in C#. And it's certainly not more verbose in F#.
That's what I meant by "OO services" in original comment: a class (or composition of classes) that maintains some state e.g. a connection, maybe some cached data or whatever, and wraps some third party services or DB calls, etc, and optionally create an interface it implements, for IoC and/or unit testing. This works quite well in F#. F#'s anonymous classes are a great conciseness aid there too (C#'s aren't sufficient; they're really just anonymous records).
It's just all the class inheritance hierarchy stuff that is uglier in F#.
> It's just all the class inheritance hierarchy stuff that is uglier in F#.
Yes, and that makes it harder for F# code to effectively re-use existing C# libraries. I know it is _possible_, fsc can reference DLLs no problem but unless that code was written to be idiomatic F# then I will have to awkwardly write some classes with a worse syntax than C#.
