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.
Thanks deeply for those who supported this idea and those who remained open to it on the other. This is how even a big company like Microsoft can stay ahead of the curve!
Congratulations all around!
David Neale commented
Thanks for the update Clint. Now we can get back to developing great things in a great language :-)
Great news Clint! Thanks for Microsoft for taking this on and doing it properly!
Chris Keenan commented
I am waiting for .net native before I can publish my F# app to the windows store. It is OK if support is just for libraries.
It's not only about F# but .net as a whole. Any .net language should have native compilation and therefore Windows Store support. Any language -> IL -> native.
Some Idiot commented
David & Onur, you are far too kind. UWP group needs a serious flush, and replaced with employees that care about Microsoft and also understand its technologies. This group has checked out and does not show the passion (and competence) other Microsoft groups show, notably Azure and VSO. It certainly feels like a checked-out group that is just collecting a paycheck, waiting for someone to sweep them out, which is exactly what should happen. Even with feedback here on the board it is far too sparse and even with Clint's "checkin" here we are going on a month now without a reply amidst some very intense and thoroughly damning feedback here. Other popular votes are going on over a year now without a response or update. That is not dialogue or customer engagement (which is separates UWP group from other Microsoft groups), that is simply getting by, waiting for anyone with authority to notice -- or care.
It is truly sad to see a technology labeled as ".NET" and it simply not live up to the name. It's almost as if a team of Apple or Google engineers snuck in there and is trying to sabotage this technology for their own benefit. Unfortunately, that is far too complex an explanation of the sad situation that we currently face with this group. Incompetence or corporate malfeasance? You take your pick. Upon reflection we will ultimately have to go with utter incompetence as F# does end up working on Apple and Google platforms, after all. I mean, you can't make this stuff up.
A ".NET" compiler without support for F# -- or any language! -- is like building a car without an engine in it. Sure it looks like a car, and for all intents and purposes it is a car, but one of its defining, powerful aspects that truly make it what it is is absent. It is as if everyone understands Microsoft technology except this group.
F# is not the end of it either. They are guilty with their flagship UWP port as well, trying to copy concepts from WPF and failing miserably. Have you not seen the votes on this board for all the missing functionality in UWP and in particular its Xaml capability? Simply a shell of legacy technologies -- with the adoption rate to prove it.
There is no passion here. Just paychecks and clueless nut-scratching over business and use cases. Also, having to ask "what's the use case for that?" is a sure-fire clue that someone has passed their prime, leaning on organizational dysfunction as dead weight, and should be fired immediately. I hope the right thing is done and a full, comprehensive purge fixes this scourge from Microsoft soon enough.
@David, I think you are mistaken. No body is worried about F#. People are worried about UWP.
Actually number of people who are exposed to F# is far greater than to people who are exposed to Windows Store apps. So in this sense, there is no doubt F# is more significant than UWP although this comparison is a bit like comparing apples and oranges.
I know F# is used in the server side as well as ios android mobile apps. It's just sad instead of UWP having strong start from the beginning, instead they killed it for F# enthusiasts and people who were looking to port their old desktop apps or mobile apps to windows platform. Now people who thinks functional programming is the future will ignore UWP and focus on other platforms. Take a look at ios swift. Take a look at C# 7 speculations (being more functional , pattern matching etc) Obviously UWP team is swimming towards the opposite direction than rest of the world and trying to rationalize their attitude with some irrelevant statistics. All they have to do is to make .NET Native support optional. Let the developer decide to it rather than making mandatory. So this is a business decision than a technical problem. And a very false one.
David Neale commented
Anonymous - Microsoft no longer has choice of dropping F#, it's all open source, including all the visual studio integration, so don't worry about that. We just need them to make C# Native into .net Native as they have named it, or allow UWP apps to just run using the regular CLR with JIT. There is plenty of use for F# outside of store apps of course, I'm using it for backend services and desktop applications, it's also great for web development and work is under way to have it running on the CoreCLR as well. So don't be afraid!
I love F# but after seeing where MS is heading (and reading all these comments didn't help either) I am too afraid to invest more time and effort into F#. What I am afraid of is that MS will drop it like it did with Silverlight but the whole situation is more like what happened to the DLR and its languages like IronPython. The one thing they have learned from the Silverlight case is that instead of publicly announce a death sentence of a tech it is better to silently abandon it and let it wither away.
What was the point of publishing F# and not giving it the tooling support it needs to prosper? MS is alienating more and more developers.
People who want to develop mobile games for android and ios with F# can use it via Unity 3D:
If Microsoft deems F# a viable option it is mandatory to fully support it.
Same goes with UWP- another fiasco like WPF and Win 8 could very well push away even more developers from Windows as a dev. platform.
Ichiro Ota commented
Not surprised to see usage with Windows 8 Universal Apps was low, considering that F# was supported only in form of PCL, which was somewhat (= very) annoying to use.
Having done a bad job to support F# and stating F# usage was low sounds a bit self fulfilling.
exercitus vir commented
Microsoft needs to realize that no one develops primarily for WinRT because the market share is so small. Instead, developers port their Android and iPhone apps to WinRT if it isn't too much trouble. Xamarin is what makes this possible, which does support F#. If you don't support F#, then you will simply lose even more market share.
And if you don't choose to support all and any .NET language, then you might want to rename .NET Native to C# Native or VB Native. Otherwise, that name is misleading.
I have a UWP app in the Win 10 store right now, and there is a component I'm thinking about implementing. It is functional in nature, and I would do it in F# in a second if I could. In fact, it would be fairly painless to do it in F# even though it would have to be in a separate library.
Furthermore, I have an app in the Windows 8 store (2048 Sandbox) that actually uses F# for a large part of the game board UI (it's actually one of the 0.01%). I would not be able to port that app to Windows 10 UWP without some serious rewriting of F# code in C#.
"Low historical usage of the language" is a false statement when considering F# is relatively a new language and the lack of tooling support for it. What would anyone expect?
I don't think decision makers on this are aware of the advantages of F# over C# With F# we can turn ideas to prototypes and working apps way faster than C# and with less resources. This means more apps entering to windows store frequently. MS should invest more to F#.
Even Don Syme, the lead of F# who works for Microsoft wants this feature.
Hahaha, typical Microsoft, never learned from past mistakes. Keep chasing developers like that, no one will develop windows apps. 0.01% my ***.
The low number of F# applications as you cite, is a direct result of your lack of tooling support for F#.
Forcing F# developers to have an hybrid application C#/XAML gui + F# portable library means only the more persistent will go that route.
Almost everyone else will give up and go full C#, given the constraints you impose on them.
Microsoft should decide how serious it is with F# and give a clear message.
Even C++ now has better tooling support.
In this article, I try to make the case for .NET Native support for F# more generally -
Whether or not that's crucial to include support in UWP, I'm not quite as clear on. Couldn't hurt, I guess :)
Patrick Hensly commented
Hi! Thanks for the response Clint. It seems to me that currently, .Net Native is not language agnostic like the rest of the .Net Framework. .Net languages normally compile to bytecode CIL (Comon Intermediate Language) which allows developers to use a multitude of languages to target the .Net Framework, from IronPython to F#. I think a better long term strategy would be to support all languages that go through the Common Language Infrastructure via compiling the emitted CIL in .Net Native.