You seem to have read past much of my comment :) > Try that on .NET Native apps. For a real-world workaround, here: https://docs.microsoft.com/en-us/windows/u

You seem to have read past much of my comment :) > Try that on .NET Native apps. For a real-world workaround, here: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root https://docs.microsoft.com/en-us/windows/uwp/porting/desktop... To quote from the thread: [by] “.NET Native doesn’t support F#,” what’s meant is “.NET Native doesn’t support all of the IL produced by the Visual F# compiler.”, which is one of the MANY reasons MS is now allowing UWP variations. > No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop. This is a reply to a comment saying "Having application libraries in C# and domain code in F# is a common pattern. Particularly at the GUI level, extra-particularly with anything that uses databinding so your domain types can be used directly." That directly addresses what you're talking about. And, because I've done it myself: it's not entirely true what you're saying here. Those languages bind and analyze .Net objects. What you're talking about is entirely GUI level, and already recommended to take in C#. The domain modelling productivity advantages CRUSH any gui nonsense. That's before we look at stability and correctness. And error rates. And maintenance productivity. At the same time, to be blunt: there's no reasonable, scaled, approach to developing applications for any of those technologies that doesn't involve separating domain logic and GUI logic. Using DDD, MVVM, three-layered-app design, or any separation of concerns really and your app will already have the logical divisions required for a C#/F# split, so you can combine the high productivity on the back end with whatever button tweaking you require.