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 Levick commented
Thanks for taking the time to hear these concerns. My team has built a very popular Windows app, Wunderlist, which was recently acquired by Microsoft and is regularly demoed by Satya Nadella. Some of our internal build tooling is written in F#, and our lead Windows developer has expressed great interest in rewriting large swaths of the app (if not the whole thing) in F# if the support were there (and guaranteed to stay there).
I am now working on the OneNote team. A group of us have expressed interest in using F# for a production project. We even began the project with F# but abandoned it due to lack of support from .Net native. We were tempted to continue anyway as we felt we could be that much more productive in F# that it was worth the risk that .Net Native support would come too late for us. However, despite the willingness to leap over mountains to be able to use F#, we decided to go back to C# because the obstacles became too high. We even considered first building the app for the Apple platforms because we would be able to leverage Swift as a modern and productive language (even though in my eyes F# has Swift beat).
Calling F# a "first class citizen" of .Net is misleading. Even server side (where I assume the usage percentage is much higher) F# still does not get shown the same love from Microsoft as its more imperative brother does.
I think if you want the Windows ecosystem to be attractive to developers your tech stack needs to have both C# and F# as true first class citizens. This won't solve all your problems, but it will certainly not push developers away as it currently does. F# support is worth it now and will only become more worth it as the software industry continues to see the benefits of the functional paradigm.
Now I'm developing Windows Store App which main logic is written in F#.
If I can use F# for UI layer, I wrote whole App in F#.
Why Microsoft guys doesn't understand F# power? F# is far and away more productive than C#.
If you support F# as first class language, I'll drop C# and write all app and software in F# for client side and server side.
Please allow me to use F# at least for main logic of UWP ,or as a UI layer library if you can.
Please,Please understand how F# is awesome. Please understand how MS made little of F#.
I think Xamarin treasures F# than MS. Why?
Hi Clint. I really can't see the reasoning behind this. Everything points toward functional programming beeing the future and also risking alienating .net's most enthusiastic crowd just seems like a daft move. Most other platforms today have solid functional alternatives and decisions like this are not going to attract any of those writing UWP apps. If Microsoft would give F# the support it deserves I am sure many of the strongest UWP apps would be written in F#.
I had actually written a small app for Win8. It was a 'strange attractor' visualizer, so no real business value except pretty pictures.
The 3D code was in Babylon JS and the computation code in F#.
But I could never get the GUI to work right ;-)
What's the point of a user feedback voting system if you don't trust its numbers? Also you mention Win 8 numbers but you forget that the platform had very few professional apps and that Microsoft was downplaying .NET. Times change man. C# has stagnated and some of us have moved on.
I have a popular app in the store called iCircuit - been there since the beginning.
However my newest apps are all written in F#.
Microsoft seems to be very hostile against F# however so I'm not sure if I'll ever publish in the store. I have an easier time writing F# iOS apps than Windows.
Zhengbo Li commented
The idea that windows store allows F# as a implementation language provides incentive for me to actually start to learn about it in the first place. The reason that F# was not widely adopted in win 8 may be it wasn't treated as a first class member anyways.
Jack Fox commented
The idea of UWP is very appealing to me, and I can think of use cases involving Azure storage because I typically work on up to 6 different devices over the course of the day. Sure would like to keep my work synchronized.
However, I am only interested in developing with F#. It allows me to express my ideas rather than obsess about implementation. And when it builds, it pretty much just works. Good test coverage is easy to implement.
Joerg Beekmann commented
As someone trying to select a new technology stack the support Microsoft gives technologies signals intent. If f# is not supported everywhere I ask myself why? Similarly if UWP and windows store apps do not support the best of the MS languages I also ask myself why? Is UWP like silverlight, a throw it at the wall and see if it sticks kind of thing that is best ignored in favour of webapps? Or is it something I should pay attention to?
I'm the developer of a Windows 8 app in the store (All About Money - which is one of the top apps in the Finance category in the store) - the one who originally posted this suggestion - because I wanted to port my app to F# to make it easier for me to keep maintaining it for now and the future.
I've got all my libraries written in F# as PCLs now. But I can't turn on .NET native - because the tooling doesn't let me : no support for F# libraries.
As many here have mentioned - the reason you're seeing very low usage ~0.01% of F# in the Windows Store catalog is due to very poor support for F# in the first place. So I think the stats here are just causing confirmation bias in this case.
I think you'll agree here - it is way more than just a bunch of F# fans saying we want this supported in UWP.
As many here have pointed out - using F# and the increasingly popular functional programming approach - to design and develop our applications will produce better quality apps for the Windows store and UWP beyond the store.
As of now - there seems to be no way for me to ship this app and get the performance benefits from .NET Native. I'll have to evaluate whether it is even usable/shippable without .NET Native support.
What's interesting is many developers using something like Xamarin get good F# support on other platforms when doing mobile development.
I do hope you'll review the decision with Windows 10 and UWP dropping F# support - and Microsoft would treat F# as a first-class citizen in the .NET / UWP world again.
Ryan Riley commented
As addendum to my earlier comment, we (a Silicon Valley startup) are only using .NET and Microsoft tools at present _because of_ F#. Were it not for F#, we would likely be a full-stack Python company. F# has a very good chance of reaching into markets where Microsoft and even Java are typically avoided. My only blocker when evangelizing F# to other startups is in the tooling and support. Your reply, while welcome, is a perfect example of why you see such little adoption of F#.
Kit Eason commented
At the risk of sounding snarky: the answer depends on whether you want UWP to succeed. People are very jumpy after what happened with, for example Silverlight and WPF. For UWP to work long term, developers, users and corporates need you to demonstrate that you are really *really* serious about the platform. One of the cheapest ways for you to do that is to support best-of-breed technologies that you already have. F# is among these. You can't complete with Apple on their own terms, as they are masters of the walled garden. So fight on your own terms, and take your ready-made developer community with you.
Isaac Abraham commented
It works both ways. As an F# developer, I'd be much more likely to look at Win10 apps if there's F# support than if there isn't any.
David Neale commented
Clint, Thank you for the response and further question!
I think other commenters have hit the nail on the head here, Windows 8.1 apps was not where we wanted to be making apps, so of course there was low usage. But since then F# has been gaining far more interest (functional in general, look at Apple with Swift for instance). Now you have a platform where people would be wanting to write LOB apps for instance, something nobody would have wanted to do before as you would have had to make them publically available, Now we have an increasing number of people moving to F# because of the benefits in terms of productivity and reduction in bugs etc. Now you have a platform (Windows 10) where the adoption rate will be high because you've got it right this time, so now there will be more of us interested in making apps.
And at this point, you have just put up a road block that says we have to give up and go back to C#.
You could at least allow UWP apps to not use .net native, and fallback to using the .net JIT again. Otherwise you are sabotaging one of the best things you've created in recent years! Just when the adoption of F# is finally happening! It always takes years for radical new things to take off, blocking it like this seems short sighted.
William Ockham commented
UWP is about far more than Windows Store apps. My interest is in Windows 10 IoT. I can put F# apps on a Raspberry Pi with Linux, but not with Windows 10. That makes no sense to me. But there is a bigger picture here.
The Windows Store is a tiny part of the target market for Windows development ecosystem and F# is a tiny part of the Windows developer community. And F# hasn't traditionally been used for that type of development. Of course there was low usage. If Microsoft's vision for UWP is limited to the Windows Store, Microsoft is blind. UWP is about reach. This move looks like the beginning of the end for F#. Why would any developer invest in learning F# when Microsoft will cut off your options? What's next? Azure PAAS?
Jared Hester commented
For the most part Microsoft's support of F# has been abysmal. It's only been on the strength of the open source community that the language has become as popular as it currently is. The lack of proper support for ASP.NET, nonexistent templates, thread-bare documentation, incompatibility with compiled XAML, and the bare minimum of features inside of Visual Studio should have held F# back, yet you have managed to succeed in spite of yourselves at creating a vibrant and productive open source community. VisualFSharpPowerTools, FAKE , Paket, FsCheck, FSharp.Formatting , FSharp.Data  are amazing tools that have transformed the way I write software and increased my productivity more than most of the C# tools that Microsoft has released. And these were all made by a relatively small group of people. Every week there are more  and more  and more  amazing F# projects being created, just imagine what could happen if you actually enabled this process instead of impeding it.
I’ve spent a fair amount of time experimenting with GUI programming in F# and higher order functions, parametric polymorphism, and partial application make it much easier to build modular GUI components for flexible reuse, but the lack of proper support cause it to fall apart in the end. FsXaml is a great library, but the creator hasn’t been able to figure out how to get the type provider to produce code that can be effectively compiled into a control library due to the wrapper classes the provided XAML have to be contained within.
You should also remember how much people disliked Windows 8, it wasn’t until 8.1 that the UX experience was acceptable, and even then adoption rates were low. The forced vertical maximization and odd division of the screen between desktop and Modern apps, and the inability to have Modern apss in windowed mode made Windows 8 apps quite unappealing. The Surface line did not seem as promising as it currently does, the market share of windows phone was (and still is) effectively non-existent. If a developer went to look in the Windows Store they found heaps of shovelware and a lack of users. So with these mounds of negatives weighing down even the consideration of writing a Windows Store app with F#, were a developer to muster the initiative to actually try to produce a Windows Store app with F#, the constant roadblocks were ample motivation to send them away. And you wonder why there were so few F# UWP apps written?
What was the value proposition of writing a Windows Store app over a regular Windows desktop application? Over using GTK# or Xamarin Forms and having it be cross platform? Over writing it for Android or iOS?
With the Windows 10 UWP apps many of the issues with the UX have been addressed and there are now unique opportunities to make it an enticing platform to develop for. The Surface 3 and Surface Pro 3 are great devices and people are actually buying them (fingers crossed for the Surface Pro 4), the Xbox One is now a viable device, the Hololens looks incredible, Cortana has a tremendous amount of untapped potential, IOT devices are a potential endless fonts of data for our type providers, and Windows Phone is still terrible, but we’re excited in spite of that!
It’s not just that we want to use Algebraic Data Types, pattern matching, first class functions, type providers, partial application, in a terse expressive syntax to write our software (which would be killer on its own), the major benefit of F# is the ecosystem of powerful tools that we can employ as soon as the language is supported properly. Somehow the tables have turned and the people are asking Mr. Ford for a car, but all he has to offer is a faster horse.
Have you considered the vast disparity between the usage of F# in the past and the interest now in using it going forward is because you guys messed up, and based on your response it seems like you’re more than ready to repeat that mistake.
 https://fsprojects.github.io/VisualFSharpPowerTools/ https://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-4c0b-8bac-86d774189cff
Juho Lehto commented
F# is truly an amazing language that is a pleasure to work with. I much prefer F# over C# for all kinds of applications, as long as I don't need to go through extra trouble to make it work. I really wish MS would recognize what an amazing language they have in F# and would proactively drive support for it.
Popularity of F# can never reach the level of VB.NET, let alone C# if there is no proper support across the technologies, this includes .NET Native, ASP.NET. WPF and so on. Support the language properly and popularity will follow.
I can't stress it enough, F# is simply amazing. Let us use it everywhere as easily as we can use VB.NET and C#.
Jarle Stabell commented
MS is doing lots of great things today, but for me it is a bit sad to see that MS seems to be unwilling to properly invest in F#, it is almost like MS is trying to downplay the usefulness of F#, implying that it is only in very limited circumstances that it is a better fit than C#, that it is only useful for "mathy" stuff. Which of course everyone having voted for this item know is wrong.
I wanted to do an UWP (initially WinRT) app, but stopped when I understood that I couldn't use F# (https://github.com/Microsoft/Win2D/issues/34). For project's where I'm my own boss, life is too short to not use my favourite language for the job. (Please don't underestimate the enthusiasts who love coding in F#! :) Enthusiastic developers matters to a company like MS.)
Stephan Tolksdorf commented
The main problem is the lack of support for F# libraries. As it is, portable libraries that want to support UWP cannot be written in F# or depend on another library written in F#. This basically kills F# for all new portable library development, particularly the development of Open Source libraries, where authors generally strive for maximum portability.
Thank you for your reply and engaging your users, Clint. Always nice to see a response from the mothership. :) I think the bigger/better question here is... why is a .NET technology not designed in such a way to allow *any* .NET language (present and future) to automatically and seamlessly interface with it? This seems to be a HUGE (embarrassing, really) oversight and makes the UWP group seem very out of touch or even a bit ignorant about the history of .NET and what it has enabled developers to achieve and the means by which they have been able to achieve it. Asking for a business case feels a bit aloof and circumspect in its own right. Developers want the FREEDOM to write their .NET applications in the language -- ANY language! -- that they desire. I think that is part of what is fueling this vote. I for one would expect whatever "fixes" this issue would fix it for *any* .NET language created going forward so that we never have to vote for something so obvious, expected, and instrumental again.
Gustavo Guerra commented
I have two WP8.1 apps that I wanted to port to UWP which I'm blocked from doing. One if them is one of the top travel apps in the UK. Probably the reason usage is so low, is that it was already hard to use F# before. On WP7 Silverlight, the whole app could be done with F#, then on Win8 and Wp8.1, entrypoint and UI had to be C#, and F# lib could only use generic libs, not having access to location and other APIs. Now in Win10s it's bot possible to use F# at all. On //build Satya suggested that app shown on the keynote could probably be done better with F#, but it's simply not possible, while Android and iOS currently can be done with 100% F#