[eurg]

> Without tons of hassle?

Well, yes and no. You definitely can do this, and for some applications it's worth it, but often the overhead at the API level will make you cringe.

APIs designed for C# are very different than APIs designed for F#, to account for partial application of functions, sum-types, non-nullability, immutability and value-like behavior by default from F# types, and also to make good use of F#'s type inference. Also, given stuff like the |> operator, making "fluent" APIs looks very different.

Using APIs made explictly for F# from the side of C# is somewhere between enormously annoying and de-facto impossible. The other way 'round, it's just massively annoying, as you lose many advantages of F#, and the code will not be much more compact as if you would write it from C#.

Pain-points in practice are around F# functions vs. C# methods and delegates, async/await vs. async-expressions, code quotations vs. Linq expressions, etc.

To be productive in F#, you want your API small and primitive, and stay within the language for the rest. If this is possible, go for it; if not, evaluate.

A final tip: Porting a big block from C# to F# is much less work than it sounds, and opens the door to refactoring that part into something sensible.

[maxxxxx]

Are there any F# APIs? I tried to introduce F# to a project but between all needed APIs written in C#/OOP style and only mild interest from a lot of developers and managers I couldn't really justify the added friction.

If there were a ton of F# libraries that showed how to create functional APIs people could learn from them by using them the same way a lot people learn OOP by using APIs.

As it is now the only way to get into F# is to have a group who really wants to do it and learn. Otherwise it's just an uphill battle.