5 ms·

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 havin

• phillipcarter 7y ago
  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 7y ago
  > 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 7y ago
    > 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.