Depends on what APIs you need, and what your tolerance is for futzing around with things. If you need the larger API surface of the .NET Framework and you don'

Depends on what APIs you need, and what your tolerance is for futzing around with things. If you need the larger API surface of the .NET Framework and you don't have time to be on the bleeding edge, go with Mono. Xamarin Studio has good support for it, and even if you're using some other editor (VSCode, Spacemacs, etc.) everything still generally works with the tooling for Mono. There are basically two components that need polishing for .NET Core to be a reasonable choice - the implementation of NetStandard 2.0 for .NET Core (so you get all the old APIs back), and for the tooling to mature (transition from project.json back to fsproj). These efforts are coming along nicely [1][2], but still aren't ready for prime time. Here's a roadmap that Enrico Sada has laid out to get the F# .NET Core situation to maturity: https://gist.github.com/enricosada/6f0a0424ca65b9d08e5a84f79560c4c6 https://gist.github.com/enricosada/6f0a0424ca65b9d08e5a84f79... And by the way, don't worry too much about switching over from Mono to .NET Core. With NetStandard 2.0 the API changes should be minimal. Similarly, once the cleaned up proj file format is out of preview the change in tooling from Mono to .NET Core should be minimal (or even non-existent). [1] https://slack-files.com/T04BJKUMU-F2ST232AJ-6e68200a3d https://slack-files.com/T04BJKUMU-F2ST232AJ-6e68200a3d - Enrico Sada's work on getting dotnet cli to work with proj system for .NET Core [2] https://twitter.com/sforkmann/status/790488306991661056?s=09 https://twitter.com/sforkmann/status/790488306991661056?s=09 - Steffen Forkmann getting Paket to work with new proj system