F# Support in .NET Native and UWP #1096
Comments
|
Please do not forget to do the groundwork for the CoreRT (.NET Core AOT) and the LLILC (LLVM based compiler for .NET Core) project too. The native target application support is important on every platform (eg.: mobile, server). |
|
Can we get a status update? :) |
|
I'd like to hear some of the progress made too |
|
Note that .NET native has been delayed across the board - it's not even made it for C# yet. |
|
That's incorrect. UWP apps must be and are .net native. |
|
Apologies, my bad. I was sure I read somewhere that it hasn't been bundled with the final release of .net core. |
|
@isaacabraham Both of you are correct. The native compiler for .NET Core is not yet bundled as open source. The native compiler used for UWP apps is proprietary. If I understand correctly they are different native compilers (though many components are shared) |
|
How long has it been delayed for? Will we at least have F# UWP for RS2 in 2017? |
|
@rogersachan: I'm under the impression that Microsoft isn't investing too much in F# anymore. Two employees (@NumberByColors and @KevinRansom) make up the bulk of recent contributions to the visualfsharp project, so the F# core team probably isn't much more than two people strong. Adding F# support to UWP is a very large task for two people to tackle. What I'm saying is that, at this point, any timely resolution of UWP support is going to be coming from the community. It's hard to come up with estimates in those cases. TL;DR: you want it, you build it. Microsoft doesn't care (for some suitable definition of "care"). |
|
@LilRed the visualfsharp team now is @KevinRansom @otawfik-ms and @cartermp . |
|
Update time! Clearing up .NET Native .NET Native is, for now, the proprietary native compilation technology used for AoT compilation of UWP apps. No other scenario is supported at this time. The .NET Native toolchain team is tackling a huge number of core issues that affect everything (not just supporting one particular language), and these are a high priority for them to fix. These issues affect key internal and external customers. Does the .NET Native Team Care about F# In a word, YES. The issues which have been found are on their backlog and they have every intention of adding support for them. But to be clear, these are not trivial to support. Tailcall optimization, for example, is a big engineering effort that will take significant time to build and get right. So where is F# on .NET Native Support Right now? Still in Investigation Mode. We get recent internal builds of the toolchain that we run tests on, we add tests to try and see what else we can break, and we report issues. These issues get logged into the .NET Native engineering backlog as soon as they come up. What can the F# community do to help? The best thing you can do is to ask for F# support (such as UserVoice) and provide examples of how you would like to write F# for UWP applications. If you have a need to write F# code for UWP apps, please reach out to me! You can email me directly (phcart at microsoft dot com) or DM me on Twitter. I want to get as much concrete info about needs as possible, as I can take these directly to the .NET Native team. Does Microsoft Care about F#? Yes! Yes yes yes yes yes! And more love for F# is coming, believe me - and not just in the OSS world. But things are taking time because so many things - the Visual Studio platform, the entirety of .NET - have been making major shifts in direction and huge engineering investments. Okay, fine, so how about some dates? As far as UWP/.NET Native support is concerned, I don't have a date for when F# support is completed. It won't be this year, though. As mentioned earlier - for example, getting tailcall optimization fully supported is going to be nontrivial and will take some time. I'll reiterate this - F# is on the .NET Native roadmap, smaller issues have already been worked on, the big issues are logged, and the .NET Native team intends to fully support F#. But .NET Native and UWP are far from done, and there are massive engineering investments yet to come. Hopefully this clears a few things up. Thanks for being understanding. If F# support for building UWP apps is essential to you, please send me at email (or DM me on Twitter) so we can set up a chat. |
|
Thank you for very detailed answer. Much needed and appreciated. However I have few opinions and questions.
|
|
.NET native is only a requirement of the windows store no? In the meantime, could we start creating UWP apps with F# that can be sideloaded or distributed through some other means? |
|
@LilRed It's helpful to distinguish between the Visual F# IDE tools, the Xamarin tools and the F# language itself. Along with many from the community, people at Microsoft contribute to the language (I've recently submitted about 20 PRs to this repo, and I work for Microsoft), some contribute to .NET Core support, some to the Visual F# IDE tools, some to the Xamarin tools, some to Azure Functions support for F#, some to data science tools for F# (e.g. Tomas Petricek is consulting with Microsoft and contributing to FSharp.Data and FsLab) etc. There is also have a very steady stream of contributions to the Visual F# docs, including many from community. That said, I think in the modern word of .NET open source, the most crucial roles for Microsoft are to enable high-quality open source contributions, amplify the base of contributors and package/deliver the software to enterprises. It's very noticeable that the areas that are closed-source such as UWP Native can become (understandable) sources of frustration, because it's plausible that the F# community could "just go fix it" if these components were open. @Reverseblade Yes, it's feasible for tailcalls just to be ignored in first-cut support. UWP Native would just have to ignore the tailcall prefix. |
|
@sefffal it is only required for publishing to windows store. For side loaded UWP apps, you can freely use F# and it will work on desktop, tablet and phone (but not on platforms that require .net native like hololens or xbox). (just make sure you uncheck .net native in build options) |
|
So we won't see anything until VS "15" I suppose (seeing as VS vNext won't be ready anytime soon), but it's good hearing that it'll be done right and not rushed through like .NET Core's implementation of F#. |
|
I know this is on a tangent, but does anyone have information as to why the UWP compiler is being kept closed-source? It seems like such a hurdle to developers. It's not like Microsoft are actually selling the compiler, they give it away as part of the Windows 10 SDK. |
This support is still in alpha ( latest docs here ), so I don't think it's being rushed (if the current bits were labelled as RTM quality I'd agree). However what is happening is that it's being done in the open. I understand that some traditional users of Microsoft's dev tooling don't appreciate it, but seeing the cake made (and contributing to it) will be more normal now. |
|
@cartermp Thanks for the update.
I am not sure what you are asking for exactly. There are over 1500 votes for Add F# support for .NET Native and there are over 2000 votes for F# support in .Net native for UWP with examples why people would like to develop UWP apps in F#. There are more votes for .NET Native support for F# than any other F# language feature request on uservoice. This is probably almost the entire F# community that signed up for user voice. Why do you ask for concrete examples? F# is a .NET language that produces valid CIL and .NET Native needs to support all valid CIL to be called ".NET". Otherwise it should have been called C# Native or VB Native. If Microsoft was really behind F# as much as you claim, then it would simply put enough resources behind it to make it work. Same with .NET Core. Talk is cheap. Show us some action. |
|
@exercitusvir For .NET Core, the most positive way to help is to contribute to the support. There is a list of known issues, though perhaps more important is trialling the existing support and reporting problems. Another significant issue is cross-compiling on Linux and Mac. |
|
Another way to help is to contribute current work in progress so vf# team can concentrate on the part we cannot do ( closed source, coord with other teams ) For example there is some to do to finish the dotnet core, lot of testing and cleanup There is also Obv it's also possible wait and ask for more developer hours, but ihmo I think this is not the right place, because here everyone agree about that. The commercial side can help about that, but nobody of them is reading these issues |
|
👍 to @exercitusvir. Truly amazing to see how long it has taken to get F# "support," and that UWP was designed in such a way that it didn't even consider it from the outset. Truly terrible and costly oversight, and reflects poorly on the entire UWP organization. Reading over the language used here, I have to say that it really doesn't sound like you are committed to F# or really have very definite plans to support it. It really sounds like a go-around, to be honest. I hope I am wrong, but I for one am not getting the warm-and-fuzzies here, and I know there are others in the votes above that are expressing that, too. The fact that you are still caught in a quagmire of closed-source considerations and old-skool roadblocks really says a lot and is not something you see from other MSFT groups these days. We're also approaching the 6-month mark of this issue being created, and it doesn't seem like there is at least an alpha/test pilot, yet? Or really, any dates to watch/expect output. Concerning. I also second the fact that you want to pull in developers for private conversations rather than listening to the thousands who have already spoken. This not only seems like you are trying to delay/fidget your way out of this, but makes me question which data you are leaning on to make your decisions on in the first place. Because clearly UWP management got this wrong. UWP group as a whole has a very bad rep of not being very community-centric, engaging, and transparent like other groups are, and it has done nothing but been a disservice for everyone involved. But truly, the greatest disservice we are all saddled with is that somehow, someway, a Microsoft-managed group "managed" to build a ".NET" technology without the ability to support all .NET languages like the original architects of .NET designed and intended. This whole debacle should be a non-issue, yet, here we are. Good to see all those infamous, iron-clad whiteboard riddles you dole out to perspective interview candidates designed to really only filter the best-of-the-best are working their wonders. 😛 Hope this isn't too harsh, as ultimately I do support your efforts -- you've got my upvote and reactions! Just speaking my mind here -- and yes, that does get me into trouble, LOL! |
|
@Mike-EEE , actually the solution is very simple. Either, They will ignore tail calls. And fix Generic support, |
Yeah... about that. 😛 Really starting to think UWP is best relegated to simply a rendering platform to render OTHER application UI built by teams who actually understand and care about .NET (like Avalonia). |
|
Meanwhile in community land: SAFE-Stack/SAFE-Nightwatch#10 |
|
Actually we started to use Fable instead of TypeScript. I am so delighted with it. It's the best thing happened on javascript for the NET community. And I am sure vast majority of Microsofters never heard of it. |
|
Any progress @cartermp ? My startup is using F# / Xamarin Forms and we want to target UWP. |
I sympathize with your situation. And I'm sorry that this makes things more difficult for you, given that you could commit to a route which can leave out a chunk of customers that you could otherwise have no left out had you chosen C#. The silver lining is that the large majority of customers you can conceivably reach with Xamarin is via iOS and Android, which are fully supported, but I suppose that's also highly-dependent on the application type. Unfortunately, there isn't a timeframe that I can share. From the .NET Native team's perspective, the single most important thing was .NET Standard 2.0 support. They had to punt bugs to get that to happen, which means they're still underwater for some time. On the F# side of things, we're also underwater in terms of the tail-end of .NET Core and its associated tooling support. When you're in that state, a long-term roadmap for support on a new platform is just nonexistent, aside from a desire to support it and occasional progress along the way. |
|
@cartermp I appreciate the clarity. Is there a timeframe for when the next section of the roadmap will be defined? At least that way we can know when to possibly expect an update. Thanks so much for your transparency and willingness to answer questions! |
|
@Krzysztof-Cieslak I am deeply thankful for all the service here and you read my comment in a different way as intended. I simply feel sometimes confused about the communication in this community. From my perspective exists here a significant challenge when it comes to the communication between Microsoft, its unemployed developers and the userbase. This does not mean that each and every member of this circle is incapable to do that. There are so many different runtimes and compilers available and they are mixable to a certain degree, developed to a certain degree, proclaimed with a certain degree of support and so on. All that with spread and diverse information. This looks of course highly confusing for somebody who is new to the project and the whole range of these available solutions lacks to provide me a simple solution, which brings the compiler with a REPL to my OS since this one uses an OpenSSL version which is released since one year. And so on and so on. @cartermp Thanks for your deep explanations.
How is Mono meant between them? Mono can use the REPL and is implemented by a lot of open source projects. |
|
@mydogisbox Unfortunately, there's none I can share at this time. I'll see if I can get any information about planning. Given that .NET Native is still closed-source, proprietary tech, I'm not sure if planning information is possible to speak about openly, though. @ShalokShalom Let's keep the discussion here focused around .NET Native and UWP support. If you'd like to discuss our priorities for .NET Core and/or tooling issues, please do open another issue. |
|
@cartermp I appreciate the clarity even if you can't share any more information. Just knowing why you can't share more is helpful. |
|
I suggest clarifying the difference between .Net Native for UWP (non-free) and .Net Native at CoreRT (open source) in the first comment and also somewhere on the F-Sharp homepage and the Microsoft Wiki. Here is an issue open now for this essential documentation. |
|
Re: CoreRT and .NET Native CoreRT may be a long way in the future. .NET Native, while unfinished, has been in production use for 2+ years, while CoreRT has no ETA and will initially support "simple microservices" link . There is some code sharing between .net native, corert and coreclr. For example tailcalls could be easier to support in future. The F# github issues for CoreRT are F# support and F# smoke test |
So, with .NET Native, you mean the UWP now, yes? Since the title of this issue suggests me, that .Net Native and UWP are two different things. So now, what I can see is the word 'cross platform' multiple times connected to the phrase .Net Native and this one seems to provide something like a machine code compiler. |
|
.NET Native is the AOT compiler for UWP apps. So this whole thread is not relevant to you. I suggest you contribute to CoreRT by trying to get F# code to build (see first link), or if you want to just use it, come back in a couple of years. |
|
@ShalokShalom I get confused by what is going on with .net. Even just following F# is hard enough. Microsoft is a vast company with lots of products, project and initiatives. Some of these things overlap, some compete and there are often huge gaps. To retain sanity I accept that everyone is doing their best, with the best intentions but everyone is focused on their own stuff with partial knowledge of things outside of that. It is reasonable to push hard for clarity in each subject but some things are out of scope and the discussion belongs elsewhere. I think you are right to ask for clarity about .net thing by raising a new issue. Let's see what happens. |
|
@cartermp What you wrote about F#, .net Native and .net Core makes sense to me. The focus on .net Core fits with the developer's division drive on Azure and the desire to be cross-platform. |
|
With Windows Mobile 10 dead, what is the market for UWP realistically ? Hololens and Xbox ? Xamarin can do Hololens, and Xbox will be game engines won't it ? |
|
Echoing a nice conversation already happening in the comments here, @davidglassborow: And by nice, I mean sad. Can you think of one group/product in all of MSFT that garners such critical (to say the least) feedback from its developers more than UWP? And for this long (years now)? It is unfortunate as it really feels like every other group in MSFT is going in the right direction except for it. Dysfunctional (to, again, say the least) handling of this issue (among many others) doesn't help its cause, either. FWIW, I will say that have learned to use the UWP group as my daily lesson in patience, as well as how to grow as a better person while learning how to handle disappointment and abject failure. That might sound like a joke, but sadly, it's not. |
|
@davidglassborow While Windows gets FCU, Windows Mobile gets the FCUK as in Fall Creators Update Killed 😄 |
That is, why other company's solve that with a specific person which interacts between all the developers and the community. Also called a community manager. That Microsoft did not solve such an issue yet, shows so clearly how crippled that Company still acts, when it comes to anything related to communication. And with that, also anything which is directly related to the community. And with that: You lack the fundamentals, how to do it honestly. |
|
I'm not really sure that this thread is being productive any more. We seem to have diverged from F# on to product planning in far away divisions. @cartermp will start a new thread with an updated F# roadmap later in the year. Thanks for all of your thoughts, comments and contributions. Kevin |
|
It might be closed, while its clearly not solved yet. That this support is so heavily depended on so many other things, shows the importance of this topic. Well, for me as a person is this development meaningful anyway, since I think its crazy to announce: "We want to bring .Net on all platforms (since we see the desktop market to collapse and the world is full with development devices on macOS and Server with Linux - uups.)" .. when you start to develop your own, proprietary toolkit which runs only on your own platform. This shows again, how less Microsoft gets the importance of cooperation. Qt is cross platform and healthy. The most frequently raised critic in my surrounding about F-Sharp is that they feel trapped in the Microsoft Ecosystem by it. So, besides all this confusing "lets develop each and every component in several different spins, while they provide more and less the very same benefit" strategy, appears it strange to me that exactly projects with the highest platform limitations receive the highest possible priority. Like in this case. And in the Case of .Net/Mono and .Net Core, where the new thing provides less serious benefits in the short and mid range, while CoreRT solves such fundamental issues as independence. I am talking here about the implementation of the REPL and so on, all these things which are supposed to work in .Net Core, while they are doing so in .Net/Mono. I understand there is a serious benefit behind them while I lack to see the logic behind the prioritizing them in front of stuff like CoreRT, basic documentation and community management. It could be that the communication about these projects is plain and simple shy and reluctant, which is why I am confused about their sense. And once again: Here is the spotlight for community management.. This specific topic is directly connected to such a sheer amount of other issues with fundamental importance and this seems to be a reason to NOT discuss it. Thanks to all those who do it |
|
FWIW @KevinRansom this issue is what is linked from wpdev's UserVoice, where it clearly says "Working On It". Might want to get that updated as well, while we are sweeping things under the rug. |
|
@Mike-EEE @ShalokShalom This site is aimed at the technical issues involved in developing the open source FSharp language and the associated tooling. This thread seems to have diverged away from that into a specific discussion of VS / Windows strategy, whilst that is an interesting discussion to have, this is probably not the right place. Perhaps the Dotnet or Windows blogs. It is fair comment that we need to update the F# roadmap, however it should be clear to everyone that the current clear focus of the F# team is cross platform with Dotnet Core and IDE tooling for that. We are a small team and work closely with the OSS community in moving F# and it's tooling forward. We have to use the resources we have to benefit the majority use cases of our F# user base, as well as to support our OSS contributors who have their own ideas about the way forward and contribute their own time and effort to make those ideas a reality. Cross Platform with Dotnet Core is a huge ask of our user base, examine Ionide adoption on Mac and Linux for example. The most common issues arising on this site are around VS tooling problems, project load performance, Dotnet SDK support etc ... We would like to have good support for Windows Store apps, but we are focusing on the immediate and pressing needs of our active user base right now. Finally, we are an active open source project and are very keen to accept submissions that would move the product forward. Please join us in making F# a productive language with appealing developer tooling by submitting code fixes and features that improve the toolset. Kevin |
|
Sounds good to me, @KevinRansom. I do appreciate the dialogue and dynamics here, much more so than UWP's uservoice. I have appreciated reading all the input and I get a much better sense of passion and traction here than at any point engaging with any UWP resource (wpdev uservoice especially). That said, the fact remains that a popular MSFT feedback vote with nearly 1,000 votes is pointing to this now-closed issue as the primary source of evidence as work being done towards the requested goal. My point was to simply point out that you now have traffic being redirected here that will no doubt expect progress (as, again, someone's "Working on It"), but will be met with a closed issue instead. Hopefully you can understand why this can be viewed as a problem. |
|
I think that ideally, an update (with a date stamp, please) of the original post would solve the majority of questions people may have that are redirected here. A pointer to an up and coming post by @cartermp about the future roadmap may also help. |
|
@KevinRansom No one is saying you should put this issue above .net core/vs2017. We just to know that the visual F# team will invest time into this when .net core and vs2017 issues have reached a good state. The .net native team has indicated in the past that they will need help from the F# team on this. While this issue can wait until after .net core support, it can't be pushed to the long term. Xamarin components are quickly abandoning Windows 8.1 support. Of the 7 components that we use or would like to use, 6 have dropped Win81 support in their latest versions. That means that Xamarin/F# users who want to target Windows currently have a very bad time, and will be basically unable to do this in 6 months. Suggest reopening issue when @cartermp gets more info on this, or creating a new f#/.net native issue if this thread is getting too unwieldy. |
|
This is continued in the CoreRT repo: dotnet/corert#5780 . |
|
[2018-12-06 update] F# UWP apps are releasable to the Windows Store. dotnet/corert#6055 |
and others
Update
See this comment
There is now an official solution by Microsoft to put a .NET/Win32 app in the Windows Store that does not require the use of UWP APIs, Xamarin, React Native, or even changes to your existing F#/.NET code, because they removed the requirement of UWP APIs and .NET Native for Windows Store apps: Desktop to UWP Bridge.
Microsoft has basically modified the Windows Store in Windows 10 to support “Desktop” apps that are not using the UWP APIs. They just need to be packaged as UWP apps and they will even run on ARM devices (through x86 emulation) that run the recently announced Windows 10 for ARM in the future,
Original Issue
We’ve been working on adding F# support to the .NET Native compiler. When this work is finished, you’ll be able to write Portable Class Libraries in F# that can be used from Universal Windows apps, which are compiled with .NET Native. Since the .NET Native compiler is closed source, this issue is here as a way to share status regularly from the Microsoft team.
As some background, .NET Native is a compiler that turns .NET IL code directly into native code ahead-of-time, rather than just-in-time. If you hear “.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.”
Outline of the work required
Identifying the specific work required
There are two kinds of issues we’re looking into: issues which we’ve confirmed by observing failing .NET Native compilations of F# IL; and issues we expect to have, but haven’t yet confirmed.
David (@NumberByColors) and Kevin (@KevinRansom) have spent several weeks working to compile the fsharp test suite with .NET Native. Most tests compiled without problems: 18 of the 23 unit tests with the coreclr tag. Several issues have been encountered in the other 5 failing tests:
A<B<C<D<…<T>>>>>) would cause .NET Native to infer the type was infinitely deep and failThere are other issues which we expect to encounter, but still need to confirm in other tests:
.tailIL instruction isn’t yet supported by .NET NativeImplement the corresponding features and fixes
The next step is implementing the corresponding fixes and features in the .NET Native and Visual F# compilers. This work will be prioritized against the other work going on in .NET Native and Visual F#. Since the total amount of work is still unknown, we don’t have an estimate for when this F# support will be finished and delivered.
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. Learn more about universal shared generics here.
Implement Visual Studio changes
Once the changes are made to the .NET Native and Visual F# compilers, the Visual F# team will need to do some work in Visual Studio to make sure F# projects behave correctly in Universal Windows app solutions.
The text was updated successfully, but these errors were encountered: