New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

F# Support in .NET Native and UWP #1096

Closed
NumberByColors opened this Issue Apr 22, 2016 · 187 comments

Comments

Projects
None yet
@NumberByColors
Member

NumberByColors commented Apr 22, 2016

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

  1. Identify the specific work required for .NET Native to support F# - In progress
  2. Implement the corresponding bug fixes and new features in the .NET Native and Visual F# compilers - In progress
  3. Implement whatever is necessary in Visual Studio to support source code, projects, and assemblies for F# Portable Class Libraries in Universal Windows apps - Not yet started.

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 bug where a 17 layer-deep nested generic type (eg. A<B<C<D<…<T>>>>>) would cause .NET Native to infer the type was infinitely deep and fail
  • A bug where enum members marked ‘internal’ would cause .NET Native to fail.

There are other issues which we expect to encounter, but still need to confirm in other tests:

  • The .tail IL instruction isn’t yet supported by .NET Native
  • Tail call optimization, which is needed for the correctness of some F# programs, isn’t yet supported by .NET Native.

Implement 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.

@zpodlovics

This comment has been minimized.

Show comment
Hide comment
@zpodlovics

zpodlovics Apr 24, 2016

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).

dotnet/llilc#980

zpodlovics commented Apr 24, 2016

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).

dotnet/llilc#980

@dsyme dsyme added the discussion label Apr 26, 2016

@lilred

This comment has been minimized.

Show comment
Hide comment
@lilred

lilred Jul 7, 2016

Can we get a status update? :)

lilred commented Jul 7, 2016

Can we get a status update? :)

@rogersachan

This comment has been minimized.

Show comment
Hide comment
@rogersachan

rogersachan Jul 7, 2016

Contributor

I'd like to hear some of the progress made too

Contributor

rogersachan commented Jul 7, 2016

I'd like to hear some of the progress made too

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 7, 2016

Contributor

Note that .NET native has been delayed across the board - it's not even made it for C# yet.

Contributor

isaacabraham commented Jul 7, 2016

Note that .NET native has been delayed across the board - it's not even made it for C# yet.

@OnurGumus

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Jul 7, 2016

Contributor

That's incorrect. UWP apps must be and are .net native.

Contributor

OnurGumus commented Jul 7, 2016

That's incorrect. UWP apps must be and are .net native.

@isaacabraham

This comment has been minimized.

Show comment
Hide comment
@isaacabraham

isaacabraham Jul 7, 2016

Contributor

Apologies, my bad. I was sure I read somewhere that it hasn't been bundled with the final release of .net core.

Contributor

isaacabraham commented Jul 7, 2016

Apologies, my bad. I was sure I read somewhere that it hasn't been bundled with the final release of .net core.

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jul 7, 2016

Contributor

@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)

Contributor

dsyme commented Jul 7, 2016

@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)

@rogersachan

This comment has been minimized.

Show comment
Hide comment
@rogersachan

rogersachan Jul 11, 2016

Contributor

How long has it been delayed for? Will we at least have F# UWP for RS2 in 2017?

Contributor

rogersachan commented Jul 11, 2016

How long has it been delayed for? Will we at least have F# UWP for RS2 in 2017?

@lilred

This comment has been minimized.

Show comment
Hide comment
@lilred

lilred Jul 11, 2016

@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 commented Jul 11, 2016

@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").

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jul 11, 2016

Contributor

@lilred the visualfsharp team now is @KevinRansom @otawfik-ms and @cartermp .

Contributor

enricosada commented Jul 11, 2016

@lilred the visualfsharp team now is @KevinRansom @otawfik-ms and @cartermp .

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Jul 11, 2016

Collaborator

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.

Collaborator

cartermp commented Jul 11, 2016

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.

@OnurGumus

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Jul 11, 2016

Contributor

Thank you for very detailed answer. Much needed and appreciated. However I have few opinions and questions.

  1. Some part of the tail call optimization is done directly by the compiler itself rather than JIT. How about adding .net native support to F# and implementing tail call support later ? Worst case we will eat the stack excessively, the loops will be slower or get a stackoverflow, I can live with this till the implementation complete?
  2. How about .NET native optional for F# projects? The only major drawback is it won't run on HoloLens and XBOX but considering there are very few UWP targeting these platforms we can live with it.
  3. How about asking assistance from xamarin guys ? Since they have already solved this problem. Remember IOS also disallow runtime code generation and xamarin does support F# iOS apps via AOT.
Contributor

OnurGumus commented Jul 11, 2016

Thank you for very detailed answer. Much needed and appreciated. However I have few opinions and questions.

  1. Some part of the tail call optimization is done directly by the compiler itself rather than JIT. How about adding .net native support to F# and implementing tail call support later ? Worst case we will eat the stack excessively, the loops will be slower or get a stackoverflow, I can live with this till the implementation complete?
  2. How about .NET native optional for F# projects? The only major drawback is it won't run on HoloLens and XBOX but considering there are very few UWP targeting these platforms we can live with it.
  3. How about asking assistance from xamarin guys ? Since they have already solved this problem. Remember IOS also disallow runtime code generation and xamarin does support F# iOS apps via AOT.
@sefffal

This comment has been minimized.

Show comment
Hide comment
@sefffal

sefffal Jul 11, 2016

.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?

sefffal commented Jul 11, 2016

.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?

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jul 11, 2016

Contributor

@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.

Contributor

dsyme commented Jul 11, 2016

@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.

@OnurGumus

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Jul 11, 2016

Contributor

@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)

Contributor

OnurGumus commented Jul 11, 2016

@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)

@rogersachan

This comment has been minimized.

Show comment
Hide comment
@rogersachan

rogersachan Jul 11, 2016

Contributor

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#.

Contributor

rogersachan commented Jul 11, 2016

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#.

@lilred

This comment has been minimized.

Show comment
Hide comment
@lilred

lilred Jul 11, 2016

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.

lilred commented Jul 11, 2016

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.

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jul 11, 2016

Contributor

not rushed through like .NET Core's implementation of F#.

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.

Contributor

dsyme commented Jul 11, 2016

not rushed through like .NET Core's implementation of F#.

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.

@exercitusvir

This comment has been minimized.

Show comment
Hide comment
@exercitusvir

exercitusvir Jul 11, 2016

@cartermp Thanks for the update.

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.

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 commented Jul 11, 2016

@cartermp Thanks for the update.

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.

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.

@dsyme

This comment has been minimized.

Show comment
Hide comment
@dsyme

dsyme Jul 11, 2016

Contributor

@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.

Contributor

dsyme commented Jul 11, 2016

@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.

@enricosada

This comment has been minimized.

Show comment
Hide comment
@enricosada

enricosada Jul 11, 2016

Contributor

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 corert and illc, that's the aot compiler, and it's oss, as alternative to the closed source .net native. coreclr too has open issues.
Other communities implement that themselves, if it's oss.

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

Contributor

enricosada commented Jul 11, 2016

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 corert and illc, that's the aot compiler, and it's oss, as alternative to the closed source .net native. coreclr too has open issues.
Other communities implement that themselves, if it's oss.

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

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Sep 15, 2016

👍 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 commented Sep 15, 2016

👍 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!

@OnurGumus

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Sep 15, 2016

Contributor

@Mike-EEE , actually the solution is very simple. Either, They will ignore tail calls. And fix Generic support,
or make .NET native optional for Phones and PCs at least for F# projects.
But all is not lost. The number of F#ers are growing and you can develop Xamarin apps with F# that runs on ios and android. Since no one actually uses UWP at all, who cares.

Contributor

OnurGumus commented Sep 15, 2016

@Mike-EEE , actually the solution is very simple. Either, They will ignore tail calls. And fix Generic support,
or make .NET native optional for Phones and PCs at least for F# projects.
But all is not lost. The number of F#ers are growing and you can develop Xamarin apps with F# that runs on ios and android. Since no one actually uses UWP at all, who cares.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Sep 15, 2016

Since no one actually uses UWP at all, who cares.

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).

Mike-EEE commented Sep 15, 2016

Since no one actually uses UWP at all, who cares.

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).

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Sep 15, 2016

Contributor

Meanwhile in community land: SAFE-Stack/SAFE-Nightwatch#10

Contributor

forki commented Sep 15, 2016

Meanwhile in community land: SAFE-Stack/SAFE-Nightwatch#10

@OnurGumus

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Sep 15, 2016

Contributor

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.

Contributor

OnurGumus commented Sep 15, 2016

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.

@jkotas jkotas referenced this issue Oct 25, 2016

Open

F# support #2057

@charlesroddie

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie Dec 12, 2016

Any progress @cartermp ? My startup is using F# / Xamarin Forms and we want to target UWP.

charlesroddie commented Dec 12, 2016

Any progress @cartermp ? My startup is using F# / Xamarin Forms and we want to target UWP.

@cartermp

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 15, 2017

Collaborator

@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:

  • Runs on all win10 devices, like XBOX
  • Sandboxed environment (if you actually want that)
  • Windows Mobile (though you should strongly reconsider not targeting this...)
  • Faster startup time

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.

Collaborator

cartermp commented Oct 15, 2017

@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:

  • Runs on all win10 devices, like XBOX
  • Sandboxed environment (if you actually want that)
  • Windows Mobile (though you should strongly reconsider not targeting this...)
  • Faster startup time

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

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 15, 2017

Collaborator

@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.

Collaborator

cartermp commented Oct 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mydogisbox

mydogisbox Oct 15, 2017

@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!

mydogisbox commented Oct 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ShalokShalom

ShalokShalom Oct 17, 2017

@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?

ShalokShalom commented Oct 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@cartermp

cartermp Oct 17, 2017

Collaborator

@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.

Collaborator

cartermp commented Oct 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mydogisbox

mydogisbox Oct 17, 2017

@cartermp I appreciate the clarity even if you can't share any more information. Just knowing why you can't share more is helpful.

mydogisbox commented Oct 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ShalokShalom

ShalokShalom Oct 17, 2017

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.

ShalokShalom commented Oct 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie Oct 18, 2017

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

charlesroddie commented Oct 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
Contributor

davidglassborow commented Oct 18, 2017

@ShalokShalom

This comment has been minimized.

Show comment
Hide comment
@ShalokShalom

ShalokShalom Oct 18, 2017

".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.

ShalokShalom commented Oct 18, 2017

".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

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie Oct 18, 2017

.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.

charlesroddie commented Oct 18, 2017

.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

This comment has been minimized.

Show comment
Hide comment
@jchidley

jchidley Oct 18, 2017

@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 Oct 18, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jchidley

jchidley Oct 18, 2017

@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.

jchidley commented Oct 18, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@davidglassborow

davidglassborow Oct 19, 2017

Contributor

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 ?

Contributor

davidglassborow commented Oct 19, 2017

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-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Oct 19, 2017

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.

Mike-EEE commented Oct 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@OnurGumus

OnurGumus Oct 19, 2017

Contributor

@davidglassborow While Windows gets FCU, Windows Mobile gets the FCUK as in Fall Creators Update Killed 😄

Contributor

OnurGumus commented Oct 19, 2017

@davidglassborow While Windows gets FCU, Windows Mobile gets the FCUK as in Fall Creators Update Killed 😄

@ShalokShalom

This comment has been minimized.

Show comment
Hide comment
@ShalokShalom

ShalokShalom Oct 21, 2017

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.

ShalokShalom commented Oct 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Oct 22, 2017

Contributor

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

Contributor

KevinRansom commented Oct 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ShalokShalom

ShalokShalom Oct 22, 2017

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

ShalokShalom commented Oct 22, 2017

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-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Oct 22, 2017

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 commented Oct 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@KevinRansom

KevinRansom Oct 22, 2017

Contributor

@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

Contributor

KevinRansom commented Oct 22, 2017

@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-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Oct 22, 2017

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.

Mike-EEE commented Oct 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@abelbraaksma

abelbraaksma Oct 22, 2017

Contributor

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.

Contributor

abelbraaksma commented Oct 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie Oct 30, 2017

@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 Oct 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@charlesroddie

charlesroddie May 7, 2018

This is continued in the CoreRT repo: dotnet/corert#5780 .
Relevant contributions welcome there.

charlesroddie commented May 7, 2018

This is continued in the CoreRT repo: dotnet/corert#5780 .
Relevant contributions welcome there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment