I developed a very non-trivial ASP.NET Core application mixing F# and C#. I learned you have to take the best parts of both languages to get maximum benefits. Specifically you're going to want a project graph that looks like this:
1. Your top-level project should be a csproj where all your "web" stuff is. Controller routes, DTOs, startup code, etc... This project is responsible for converting data into nice objects that are passed to the F# code.
2. A mid-tier project written in F#, an fsproj. This is where you can be nice, pure, functional, live out your best life pretending C# doesn't exist. However you will eventually run into issues interfacing with external libraries, EF Core, lack of standard library support for whatever you're doing. That's ok! The final layer will solve it.
3. A foundational project written in C#. This project's job is to hide the ugly and make your F# project into the functional programming nirvana you know it can be. Wrap those dependencies into pure functions, write your entity framework junk, use all the latest C# language and runtime features and expose them to your F# project.
So something like:
C# -> F# -> C#
Ultimately, I decided that C# really is good enough and I didn't see enough benefits to continue using F#.
> Ultimately, I decided that C# really is good enough and I didn't see enough benefits to continue using F#.
I’ve heard this story repeated so many times over the years. The responsiveness of the C# language team in particular (as opposed to the runtime or ASP teams, etc) is remarkable and the thoughtful inclusion of functional-inspired features over the years has really dramatically improved QOL for C# devs. (With the exception of some annoying carve outs like going too far with trying to please JS/node refugees with not only introducing support for top-level statements but also pushing it as the default in the various templates, the botched delivery of global includes, and other such changes —- but to be fair, many of these were implemented correctly and without any complaints on my end in the language itself but my quibbles are more with the delivery, integration, and polish in the IDE and downstream by teams like the ASP.NET Core one.)
After a long pause during the denouement days of the .NET Framework, the C# of today would be unrecognizable to C# devs of yesteryear, and the changes keep coming.
(All this is from the POV of a developer that’s been using C# since 2002; back when J# was a thing and I was slowly adapting to writing code in a case-sensitive manner after years of VB.)
Yes, that is the ultimate problem with F#, Microsoft behaves as if it was a kind of mistake to add it to the Visual Studio 2010, the experience always lags behind C# and VB, leaves to the community to do most of the work, and now with stuff like code generators being used everywhere is getting worse.
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#.
F# deserves a project like Phoenix that the entire community can get behind. World-class docs, zero getting started friction(docs, examples, and libraries all just work), and bomber F# APIs over any ubiquitous C# libs it might need.
1. Your top-level project should be a csproj where all your "web" stuff is. Controller routes, DTOs, startup code, etc... This project is responsible for converting data into nice objects that are passed to the F# code.
2. A mid-tier project written in F#, an fsproj. This is where you can be nice, pure, functional, live out your best life pretending C# doesn't exist. However you will eventually run into issues interfacing with external libraries, EF Core, lack of standard library support for whatever you're doing. That's ok! The final layer will solve it.
3. A foundational project written in C#. This project's job is to hide the ugly and make your F# project into the functional programming nirvana you know it can be. Wrap those dependencies into pure functions, write your entity framework junk, use all the latest C# language and runtime features and expose them to your F# project.
So something like:
C# -> F# -> C#
Ultimately, I decided that C# really is good enough and I didn't see enough benefits to continue using F#.