←back to thread

Why F#?

(batsov.com)
438 points bozhidar | 4 comments | 01 Apr 25 12:34 UTC | HN request time: 0s | source
Show context
gwbas1c ◴[01 Apr 25 13:34 UTC] No.43546622[source]▶
If you've had C# and F# co-exist in the same codebase, how do they co-exist? Is it like C# and VB.Net where a project (dll) is either C# or VB.Net, and they can reference each other?

Or: Is it more like the Swift / Objective C ecosystem where Swift, Objective C, and even straight C can co-exist in the same library?

In a mixed C# and F# codebase, generally when do you favor C# versus F#?

Coming from a C# background, what are the areas where F# is a better language?

Any success stories for F#, especially if it co-exists with C#? Any horror stories?

replies(2): >>43546727 #>>43546846 #
neonsunset ◴[01 Apr 25 13:46 UTC] No.43546727[source]▶
You have likely heard "functional core, imperative shell". This refers to having IO-heavy code that favors imperative patterns be written in C# and then have the actual domain logic core written in F# which is much better at expressing it. Because both languages are hosted on .NET, you simply achieve it by having two projects and having one reference another. It is very seamless F# and C# types are visible to each other if marked to be so.

The biggest advantage of F# is its gradual typing and full type inference which allows to massively reduce the amount of text required to describe application or domain logic. It is also extremely composable and I find doing async in F# somewhat nicer than in C# too. F# also has better nullability (or, rather, lack of thereof) assurances and, in my opinion, better UX for records.

replies(1): >>43546796 #
gwbas1c ◴[01 Apr 25 13:51 UTC] No.43546796[source]▶
That's just like how C# and VB.Net can co-exist in the same project. Would you pick the pattern of:

1: C# Library with interfaces and/or abstract base classes

2: F# library with implementations of those interfaces and base classes

3: C# program (console, web service, GUI, ect) that specifies the implementations in Dependency Injection

Or is there a simpler way for C# and F# to co-exist in the same project (dll or exe)?

replies(1): >>43549029 #
1. int_19h ◴[01 Apr 25 16:57 UTC] No.43549029[source]▶
You don't really need to split 1 & 2, since F# can define .NET interfaces and abstract classes just fine.

For that matter, you don't even need the interfaces if you wouldn't have had them in a C#-only solution. Just define the class in F# and use it directly from C#.

You still need a separate assembly for F#, but that doesn't imply dependency injection - again, just reference it and use it.

replies(1): >>43549770 #
2. gwbas1c ◴[01 Apr 25 18:06 UTC] No.43549770[source]▶
I've identified a possible use case for F# in a preexisting product; I'm looking for the simplest way to integrate F#.
replies(1): >>43550653 #
3. Lanayx ◴[01 Apr 25 19:45 UTC] No.43550653[source]▶
F# excels in writing domain logic where main domain entities are defined as records and discriminated unions and logic is written in pure functions. Given that product is preexisting and domain entities must already be defined, I wonder what use case do you have in mind?
replies(1): >>43553295 #
4. gwbas1c ◴[02 Apr 25 03:04 UTC] No.43553295{3}[source]▶
Realtime control logic for infrastructure.

The basic decision making logic needs to be very simple and easy to follow by scientists and people who aren't day-to-day software engineers: Basically, input some data, such as sensor readings, run it through an algorithm that makes decisions, and then output the decisions.