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.
"With Windows 8 Universal Apps, we did support F# as a library (although not for full apps) but usage was very low (~0.01% of total catalog". Careful Microsoft! https://github.com/willsb/MvvmCross.FSharp
David Bottiau commented
I feel disappointed that I can't use F# to create a UWP application.
If not .NET native / UWP, is it possible to use F# with Xamarin which I believe does native compilation?
After one year since has been flagged as WORKING ON IT , the support for .NET Native is not even in roadmap https://github.com/Microsoft/visualfsharp/issues/2400.
Josh McFadden commented
+1 to the sentiments expressed in here. This used to be one of the greatest groups in Microsoft, and now it is simply an embarrassment. We are pushing nearly a decade now with the same mediocre featureset with no passion or desire for improvement. Not supporting a .NET language in a .NET technology offering is the cherry topping on the cake of fail. Taking years to pacify angry developers with empty words in the meantime is a despicable achievement.
The good news is that it looks like they are finally wisening up to all the dead weight that is wasting space there. Hopefully they are prudent and hit everyone responsible in the Windows Group for this disaster:
Make Microsoft Great Again!
Marco Murray commented
Seen recently from the redirected thread above:
"the ability to use F# in a UWP app likely won't be available for some time."
I've seen some people joke on here and on a few blogs now that this group does nothing but play Halo all day. While funny, I am starting to think there is some merit to it. I am in agreement with others posting here. This very popular idea has been on the books for over a year now, and it sounds like there is at least as much work left or more to do on it -- that is, if there is actually anyone over there that does any work!
It is quite clear the UWP group doesn't understand .NET and the fact that one of its premiere languages has not made it to its quite mediocre platform that no one has adopted is simply unacceptable. The only thing more shocking is that those who continue to butcher the vision of .NET are still employed and continue to make a paycheck doing it.
UWP and the "brains" behind it is truly the worst thing to happen to Microsoft since Clippy and Sinofsky. Sinofsky, incidentally, made Clippy and actually admitted to it. Microsoft actually did the right thing here for once and dumped him once that admission was made. So there is hope!!
Maybe it's time to start poaching back the quality engineers who all flocked to Google, or at least consider being like the rest of Microsoft these days and make this project open source!!!
Or MAYBE require some of the UWP "engineers" to get their heads out of their video games and take a few Pluralsight courses on .NET. The incompetence here is truly staggering!!
Titus Rockefeller commented
Did anyone bother to read the language used in the GitHub issue? It reads like "yes, we're committed to F#, but not THAT committed." This is an embarrassment! A travesty! How do you design a .NET technology but do not support .NET languages? You know where F# works? It works in WPF, and even Xamarin allows you to use it. You can even use it to make a console application. A CONSOLE APPLICATION!!!
Why even bother calling UWP ".NET"? That is probably the worst mistake out of all of this. If this wasn't labelled as .NET, then no one would expect the .NET qualities that makes .NET so great. Well, great outside of the twisted, messed up, upside-down cluster that is the UWP group, which definitely has its own version of what .NET is supposed to be, and has failed terribly in making it happen, both in implementation and adoption.
Everyone is truly hoping for an outside group to clear out this cruft known as UWP group and bring back our .NET the way we enjoyed before the clowns took over.
Bradley Masterson commented
Does anyone over there care? Do you not understand your own technologies? Truly a drop in talent and passion in this group.
Carl Patenaude Poulin commented
It's almost the one-year anniversary of this (very popular) feature request and it's still a work-in-progress :(
RJ Wilco commented
Good to see the efforts here. F# is pretty great and looks like it is a cheaper way of developing applications. I might make the jump from C# to F# soon... granted all the good tech supports it!
Jack Fox commented
thanks @clint, your efforts and the update are very appreciated by the F# community.
Ryan Riley commented
That's a fantastic update! Thanks!
Stefano Pian commented
Two months have passed since the last admin comment.
Clint, can you share any news on the progress for F# UWP (or lack thereof)?
My company will be starting a UWP project pretty soon and I'd love to *at least* be able to include some F# library.
Yeah any news? I wanted to implement more logic in F# in our company but right now it's impossible.
Booker T. J. commented
> I'm following up with the team now.
Soooooo... after 16 weeks, what did the team have to say?
Marco R. commented
Fair enough Jarle. I am more interested in transparency than apology. Although it is impressive/valuable to see apology from VSTS as they are working with actual deployed, complex software. Their problem happened in the field 2 days from the updated post. Here we are dealing with a "working on it" going on 15 weeks without update. If they are working on it that is either 5 or 7 sprints depending on cadence. Hope that makes sense. Agreement on the human factor, and really interested in seeing something (anything) like the referenced post outlining steps, efforts even if that means they f'd up and really have been playing Halo this entire time.
Jarle Stabell commented
@Marco R., for all we know, the team may be doing an awesome job with this complex technology, demanding an apology for not having shipped something yet (and without any promised dates) is unfounded and counterproductive. Remember that the people working with this are only humans, most likely doing their best under the circumstances.
Marco R. commented
How about a post and apology? like this for what is taking so long:
@Paul, can you email me, firstname.lastname@example.org. We would love to better understand your apps.