F# support in .Net native for UWP
There has been some discussion on the blog post http://blogs.msdn.com/b/dotnet/archive/2015/07/30/universal-windows-apps-in-net.aspx?PageIndex=2#comments for supporting F# in the .Net native toolchain for UWP. I had posted this on the VS uservoice site https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/7542181-add-f-support-for-net-native but it looks like that was the wrong place to do that. I hope the votes that request got will be considered for this. A lot of people are moving to F# PCLs for library code and to be able to use those PCLs in the UWP and get native compilation via .Net native tools would be great.
F# team just posted an update on their GitHub. https://github.com/Microsoft/visualfsharp/issues/1096
This is still a work in progress. One key thing from that post is some of these features and fixes have already been underway for months. While we’ve been investigating F#-specific issues in .NET Native, the team has continued to improve .NET Native. One feature known as “universal shared generics” is likely to have improved .NET Native’s support for F#, even without that being an explicit goal of the feature.
Ryan Riley commented
Hi, Clint. I think many of us want .NET Native support for IoT purposes. Many others, including my company, build mobile apps in F# on Xamarin and would like to be able to also support Windows.
F# library support in Windows 8 (PCL) was very weak and had many problems. For the most part, it was easier to port the code to C# than to try to get it to work. Also, given MS did not support F# all the way to the UI layer, you were certain to see very low adoption.
As a better metric, consider the use of F# for building Xamarin applications on iOS and Android. While still a small percentage, I think you'll find it significantly higher than what you saw in the Windows Store. Full support goes a long way to giving you more reliable metrics.
I absolutely need this for Nu Game Engine, the world's first practical, pure functional game engine in F# - https://github.com/bryanedds/FPWorks
While the game engine is already reasonably fast, there's no reason it should be bottlenecked by the JIT, or to have be an even more significant resource drain on mobile. Not to mention start-up times!
Will Smith commented
This is very important to F#. We absolutely need .NET native for F#.
I spent 6 years with c#, spent a year with f# and I do not want to go back. Please support
Umut Karakoç commented
I will wait F# support to write app :(((
Amy Damerow commented
Please please please support this. I've been writing in F# so long that it's painful trying to rewrite my library code in C#. It'd be nice if I could re-use all this work I've already done.
Jacqueline S. Homan commented
You DEFINITELY have my vote :)
This will indeed be very much appreciated. With my entire team moving to F# for almost everything, it will be nice to be able to use it everywhere.
Sorry, I've accidently clicked "Flag idea as inappropriate…" on this idea. Please ignore this.
Would be very amazing to have also full F# on UWP, since i started to use F# on the last months is really a pain have to go back on UWP
David Neale commented
F# generated assemblies really need to be fully supported, not just PCLs. Functional coding is very much the up and coming way to build all kinds of software and the single biggest market is going to be UWP apps across all device types so we really shouldn't be forced back to imperative coding for those, when we can make higher quality apps (less bugs, better use of multiple cores etc.) using F#.
Tuomas Hietanen commented
Currently Windows 8 preview don't support using F# and Rx out of the box. They should.