←back to thread

Why F#?

(batsov.com)
447 points bozhidar | 1 comments | 01 Apr 25 12:34 UTC | HN request time: 0.205s | 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 #
1. debugnik ◴[01 Apr 25 13:56 UTC] No.43546846[source]▶
Yes mixing is just like with VB.NET.

When mixing, you often write business logic as self-contained F# libraries with a C#-friendly API; and use C# to integrate them with whatever imperative, reflection-heavy and DI-heavy frameworks .NET is promoting the current year, since those are filled with interop edge cases for F# anyway.

You really want to avoid a language sandwich though (e.g. C#/F#/C#), because you'll keep wishing to remove the middle layer. Sadly, the addition of source generators make this mistake even more appealing.