[nulagrithom]

While we're hijacked...

Is F# still the red-headed step-child of Core?

Last I fiddled with it F# was looking pretty unloved, but to be fair C# was still having a hard time with Core itself.

[phillipcarter]

Sounds like you popped in before mid-2017 when things were rough all around. F# is fully supported on .NET Core and, including tooling in VS. Give it a shot!

[McWobbleston]

> Is F# still the red-headed step-child of Core?

Yup. Although this doesn't really come into play with server code in my experience. I don't imagine I'd want to deal with it writing WPF / UWP things though where language support is more important

Even then I might just write the business logic in F# and glue things together with C#

[wyoung2]

> I don't imagine I'd want to deal with it writing WPF / UWP things though where language support is more important

As the article points out, there never has been any visual forms designer type stuff for F#, so if you're writing a GUI app with F#, it's best to wrap it in a C# shell anyway.

Which is fine, because you wanted to separate your core application logic from the GUI anyway, right?

> I might just write the business logic in F# and glue things together with C#

It's a perfectly reasonable way to go.

The only difficulty is that it simplifies things if you don't try to do all the fancy FP stuff at the boundary between the F# and C# parts of the app. While there are ways to pass, say, a tuple from F# to C# and cope with it on the C# side, it's better to limit types at this interface to things both languages support as first-class citizens: arrays, objects, simple scalars, etc.