Closed NumberByColors closed 6 years ago
jchidley
commented
6 years ago Can we please update the top level comment, or give a full update somewhere, or explicitly state that nothing has changed? It's been 18 months and I'd like to see an up-to-date status somewhere.
cartermp
commented
6 years ago @jchidley The top-level comment has the most recent update at the top. You can use the desktop bridge to distribute an F# desktop application through the Windows Store.
mydogisbox
commented
6 years ago @cartermp I think he (and myself plus a lot of others) are looking for updates on full UWP support for F#.
cartermp
commented
6 years ago There is no current timeline. I don't know what the current blocking items are, though last we checked, non-trivial stuff simply failed:
(from copy/pasting psuedo-randomly from here)
From the F# team's PoV, .NET Core, its associated tooling support, Type Provider support on .NET Core, and proper FSI support on .NET Core take priority over .NET Native support. Given the larger usage of .NET Core than UWP, we think this prioritization makes sense.
The .NET Native team just finished .NET Standard 2.0 support, and once the bug tail for that is shortened, bringing up F# support for their runtime may be on their plate. I don't know their priorities post-.NET Standard 2.0.
charlesroddie
commented
6 years ago Thanks for the details Philip. Was that a recent check? Asking because a year ago Matt Whilden mentioned that printf gave rise to highly nested generics that were causing problems, but a month ago Kevin said generics had been fixed.
Noemata
commented
6 years ago @cartermp UWP's reduced usage is precisely why it should be given priority. I suspect its "non-trivial" support issues are a significant factor contributing to the tendency to go after low hanging fruit. UWP must be given priority within Microsoft if it is to be regarded more seriously externally. It is a new platform, and the more tooling that supports it, the more attention it will get. Do you not take particularly special care of your seedlings/little children/(substitute your own analogy)?
mydogisbox
commented
6 years ago @cartermp I don't at all disagree with the priorities you've given.
The issue I have is that the complete absence of any sort of timeframe makes certain commitments to using F# more risky than is potentially necessary. If, for example, I write a Xamarin app in F#, will there come a time when I want to add an Xbox app using the same business logic? If so, then I suddenly need to do a complete re-write of my business logic. Knowing some sort of timeframe at all would make that decision easier to make.
OnurGumus
commented
6 years ago @cartermp, that was a great response that everyone was willing to hear. But since you said
I don't know their priorities post-.NET Standard 2.0.
How about asking them? As an insider you surely have better ways of communication with them compared to rest of us.
ShalokShalom
commented
6 years ago As an insider you surely have better ways of communication with them compared to rest of us.
That this is obviously not the case, frightens me. I know another Insider and he is also very much in confusion, what is coming up.
Seems like a huge number of open source projects share more info with each small member, as Microsoft does with even their "insiders".
Krzysztof-Cieslak
commented
6 years ago I'm pretty sure that @cartermp knows how MSFT works, and how to do his job better than you.
jchidley
commented
6 years ago Thanks @cartermp for your replies. You wrote "From the F# team's PoV, .NET Core, its associated tooling support, Type Provider support on .NET Core, and proper FSI support on .NET Core take priority over .NET Native support."
Given that comment my focus for F# will be to program for .net Core.
.net Native/UWP has an unknown timeline and other versions of .net are the past.
@Krzysztof-Cieslak @ShalokShalom @OnurGumus I used to work for MSFT for 15 years in various jobs that required me to understand various product teams' short, medium and long-term plans. All you can be sure of is your business' plans for this financial year (1st July to 30th June), a reasonable grasp of it's plans for the next couple of years and an idea of its aspirations beyond that. Anything else is speculation.
I am treating @cartermp comments as authoritative for F#.
OnurGumus
commented
6 years ago Though one thing puzzles me. Looking to the top most update of this issue, now non UWP applications are accepted ( and even encouraged )in the Windows Store, why still enforce .NET Native for publishing UWP apps ? I mean perhaps I want to publish my UWP app in a non UWP way. Is it a worse solution than publishing a non-UWP app ?
cartermp
commented
6 years ago @jchidley
.net Native/UWP has an unknown timeline and other versions of .net are the past.
I wouldn't really say that. .NET Framework is perfectly relevant today. Not only is it the runtime that the largest chunk of .NET (and F#) developers run code on, but it's grown quite a bit over the past year. Since F# and all of its features and tooling work on .NET Framework, it's absolutely a good target for your next F# project.
This statement:
Given that comment my focus for F# will be to program for .net Core.
Will be both a struggle and a pleasure, depending on what you're doing. .NET Core is the primary focus of the entire .NET organization, and thus will have the best runtime features, standard library improvements, ASP.NET support, EF support, and so on. The .NET team is committed to porting improvements over to .NET Framework when possible, but the "latest and greatest" stuff will be on .NET Core.
However, it's not as mature as .NET Framework yet. For example, Type Provider support is still underway, and F# Interactive doesn't work there (...it's slightly more complicated than that, but it's best to just say it doesn't work). So, should you bet the farm on .NET Core? A few folks have, including the backbone of their business, and it's worked out for them. But they've also scoped what they're doing to backend services and/or cloud programming. If that's your aim, then it's a good choice. If it's not your aim, then there may be struggles.
@OnurGumus
Though one thing puzzles me. Looking to the top most update of this issue, now non UWP applications are accepted ( and even encouraged )in the Windows Store, why still enforce .NET Native for publishing UWP apps ?
I'm afraid I don't know the real answer to that. .NET Native does provide some affordances:
So I can only presume that the goals of UWP, at least at its inception, include those four points (and others). A desktop-only .NET Framework app deployed via the Windows Store violates those points.
@charlesroddie
Thanks for the details Philip. Was that a recent check? Asking because a year ago Matt Whilden mentioned that printf gave rise to highly nested generics that were causing problems, but a month ago Kevin said generics had been fixed.
This is fairly recently, so I suspect that this issue has not been fixed, or at least not to the degree that printf with higher-order functions works.
@Noemata
[UWP] is a new platform, and the more tooling that supports it, the more attention it will get. Do you not take particularly special care of your seedlings/little children/(substitute your own analogy)?
Although I agree with this in spirit, the fact of the matter is that UWP is just one of many platforms for .NET. Our charter isn't to push Windows exclusively, and our priorities are in making .NET the best cross-platform stack out there. This gives us more reach, results in more users, and legitimizes .NET (and F#) in ways that it wasn't seen as a legitimate option in the past.
Put differently, my goal is to ensure that the phrase, "If you have to use Windows, you can use F# which is sort of like OCAML" is never uttered anymore. That means prioritizing cross-platform .NET support through .NET Core over .NET Native support from the F# team's perspective.
cartermp
commented
6 years ago @mydogisbox
The issue I have is that the complete absence of any sort of timeframe makes certain commitments to using F# more risky than is potentially necessary. If, for example, I write a Xamarin app in F#, will there come a time when I want to add an Xbox app using the same business logic? If so, then I suddenly need to do a complete re-write of my business logic. Knowing some sort of timeframe at all would make that decision easier to make.
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.
mydogisbox
commented
6 years ago @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!
ShalokShalom
commented
6 years ago @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. It means simply, that the current situation is challenging to me.
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.
From the F# team's PoV, .NET Core, its associated tooling support, Type Provider support on .NET Core, and proper FSI support on .NET Core take priority over .NET Native support.
How is Mono meant between them?
Mono can use the REPL and is implemented by a lot of open source projects. Why .Net Core, when Mono solves the issues of it?
cartermp
commented
6 years ago @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.
mydogisbox
commented
6 years ago @cartermp I appreciate the clarity even if you can't share any more information. Just knowing why you can't share more is helpful.
ShalokShalom
commented
6 years ago 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.
charlesroddie
commented
6 years ago Re: CoreRT and .NET Native CoreRT is the "cross-platform open source evolution of .net native". The current plans are more ambitious than .NET Native, "shooting for unifying dynamic code generation (JIT, just-in-time) with static code generation (AOT, ahead-of-time) so that application authors have the ability to dial how much they want to do at build time vs. runtime" link .
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
davidglassborow
commented
6 years ago ShalokShalom
commented
6 years ago ".NET Native, while unfinished, has been in production use for 2+ years"
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. I am a Linux user, so cross platform is what I am interested in.
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.
charlesroddie
commented
6 years ago .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.
jchidley
commented
6 years ago @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.
jchidley
commented
6 years ago @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.
davidglassborow
commented
6 years ago 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 ?
Mike-E-angelo
commented
6 years ago Echoing a nice conversation already happening in the comments here, @davidglassborow: https://blogs.msdn.microsoft.com/dotnet/2017/10/10/announcing-uwp-support-for-net-standard-2-0
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.
OnurGumus
commented
6 years ago @davidglassborow While Windows gets FCU, Windows Mobile gets the FCUK as in Fall Creators Update Killed 😄
ShalokShalom
commented
6 years ago 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.
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: Anything related to the development. And we are talking about one of the richest company's in the history. That is one of the downsides, when you reach this point by corruption and monopolizing:
You lack the fundamentals, how to do it honestly.
KevinRansom
commented
6 years ago 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
ShalokShalom
commented
6 years ago 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
Mike-E-angelo
commented
6 years ago 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.
KevinRansom
commented
6 years ago @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.
/cc @cartermp , @dsyme
Kevin
Mike-E-angelo
commented
6 years ago 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.
abelbraaksma
commented
6 years ago 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.
charlesroddie
commented
6 years ago @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.
charlesroddie
commented
6 years ago This is continued in the CoreRT repo: https://github.com/dotnet/corert/issues/5780 . Relevant contributions welcome there.
charlesroddie
commented
5 years ago [2018-12-06 update] F# UWP apps are releasable to the Windows Store. https://github.com/dotnet/corert/issues/6055
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.