F# Support in .NET Native and UWP

[NumberByColors]

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.

[Mike-E-angelo]

Soooooo the "working on it" from: https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9110134-f-support-in-net-native-for-uwp is ... inaccurate? Should it be updated to perhaps reflect that no one is, after all, working on it?

[Noemata]

You have to wonder how the folks at Microsoft think Windows 10 S is going to have even the remotest prospect of success given the accumulating lapses associated with UWP. F# is but a small part of the underbelly of this iceberg. It gets very hard to remain hopeful when screaming for help isn't heard.

[OnurGumus]

On the meanwhile, https://www.reddit.com/r/programming/comments/6swm9j/mono_begins_using_cf_to_webassembly_with_a_look/

[veikkoeeva]

@OnurGumus https://github.com/SteveSanderson/Blazor/pull/6 (from https://github.com/SteveSanderson/Blazor/pull/5).

[Mike-E-angelo]

@veikkoeeva while Blazor does a great service in fostering and promoting WebAssembly adoption, it is based on .NET Anywhere, which hasn't been updated in 6 years, let alone being .NET Standard-compliant. The mono initiative is much more aligned with these goals and holds more promise as far as this is concerned. Not to mention, already supports F# out of the gate. 😉

[ncave]

@Mike-EEE It was relatively painless to extend the DNA to support F#. But yes, using mature and optimized GC and JIT is probably the way forward, it would be nice to have .NET Core or Mono officially target WebAsm (perhaps in a smaller profile).

[Krzysztof-Cieslak]

@cartermp: I suggest locking this issue until there are any real news about UWP support. At this point of the time, everything what should be said was already said, and people are just starting to repeat themselves without any reason.

[vitordelucca]

Why can't Microsoft just be honest and say that is not in the works and they don't have plans and close the issue after all?

[charlesroddie]

Both the F# and .net native teams are extremely busy atm, as they have limited resources to handle the large tasks of .net core 2.0/standard 2.0/vs2017 support. UWP will only support .net standard late this year. What they can do is have a plan for work for when those efforts are mostly done, including resuming testing, communicating with the .net native team and helping them to fix the bugs.

[cartermp]

At the risk of starting another argument ... 😄

Let's not disparage Windows 10, 10 S, UWP, Visual Studio, Fable, Ionide, Desktop Bridge, F#, NET Native, or other technologies here. Frustrations are understandable, but airing those frustrations in a way which trivializes or otherwise insults others or other technologies only increases frustration.

I cannot speak towards the priorities of the .NET Native team after they complete .NET Standard 2.0 support (which is, without question, their top priority right now). But I can speak towards our current top priority: completing the Visual Studio tooling support for .NET Core and .NET Standard. Further work to complete the .NET Core picture with Type Providers and proper F# Interactive support are also a very high priority. Furthermore, the success of current and future customers on Azure is also of very high priority for us, and it is an ongoing priority that surfaces in many areas: Azure Functions, Azure Notebooks, being stakeholders in API changes for different services, etc. Not only is Azure used by many F# customers already, but it's an area of growth for F# that is also of massive strategic importance to Microsoft.

This does not mean that UWP support is somehow unimportant to us. It's clearly the future platform for Windows, and although it's not the replacement for WinForms and WPF, the ability of UWP to run on Windows Holographic devices represents an exciting area for F# and computing in general. As these devices become more widespread, I personally believe that Windows 10 will also increase in market share as it helps push the boundaries of computing devices.

But the fact of the matter is, UWP is a technology that only ~30% of the Windows market can use today. .NET Core and Azure represent a larger addressable market than UWP does, and that is where the lion's share of our time will go for now. We'll remain subject matter experts for the UWP team to work with on .NET Native support, push for F# on their priority list after their .NET Standard support is completed, and we'll also contribute in identifying problems that need to be solved for proper .NET Native support. We'll also be lending similar support to those who work on CoreRT, as true cross-platform native compilation for F# applications is important for .NET Core and Azure customers.

[Mike-E-angelo]

You're doing Good Work out there, @cartermp, and are quickly becoming a MSFT hero of mine in how you engage your community here and in MSDN blogs. Please do continue the excellence. 👍

[cartermp]

Thanks @Mike-EEE!

[pjmlp]

@cartermp Thanks for making a statement about this situation.

Our customers requesting .NET projects care mostly about desktop applications, as they tend to use other technology stacks for Web based applications, as such currently we don't spend any resources on .NET Core and Azure.

But I do understand the priorities as you explained them, looking forward to the day F# is shown on this web site and will stop complaining.

https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp#use-a-language-you-already-know

[Noemata]

@cartermp perspective is part of the problem at Microsoft. Other divisions within Microsoft have done a good job of both steering developers away from Winforms/WPF while simultaneously crippling the future prospects of those technologies. The last posting from the WPF team:

https://blogs.msdn.microsoft.com/wpf/2015/10/29/wpf-in-net-4-6-1/

would make you think that Harikrishna Menon is still plowing away at new features, but he has actually left the company. Microsoft doesn't care enough about WPF to identify a new PM. We on the outside have learned to look for signs of abandonment as a result.

So when you sell us on the idea that UWP is the future and make it clear the old tech is not being enhanced, hearing that Microsoft insiders are waiting for some sort of adoption threshold for UWP is bad news with statements like "UWP is a technology that only ~30% ...". To that I say so what! UWP started with zero adoption! Microsoft has to commit and show that it is intent on getting adoption to 100% by bringing its most powerful tooling along of which F# certainly qualifies.

I also expect Microsoft to develop all its desktop Apps using UWP. Microsoft's investment in WPF application development was nominal. Clearly, Microsoft felt the performance wasn't there, nor did the company want to use a tech that could be so easily reverse engineered (like the rest of us). Or was it because adoption was only at ~30%?

So please don't tell us why UWP isn't there yet. Make it happen!

[OnurGumus]

@pjmlp note that you can develop uwp with f# today by disabling .net native. It's just you can't publish them to windows store. @Noemata no way it's 30%, but max 3%. Almost no body uses windows store including Microsoft itself. That's why they are bringing real office to windows store for windows s.

[Noemata]

@OnurGumus the 30% figure was not my estimate, I was using @cartermp 's. Your 3% estimate is on the generous side.

So here's a little story Microsoft PM's can study in detail ...

My little company is developing a UWP MIDI application that should have been released about 6 months ago. We would really like to use F# for MIDI data transform operations since it is both elegant and succinct. Being able to call into an F# library DLL would be sufficient. We do not need XAML/GUI/IDE integration for our prospective F# libraries. We know for a fact that such an arrangement, given the current state of things, is not so far fetched and a readily achievable goal for Microsoft.

We also need a UWP MIDI stack that actually works. Currently, the UWP MIDI stack is unusable due to serious flaws that make it impossible to correctly enumerate MIDI ports or transmit certain types of essential MIDI data. These flaws date back to 2014, so you could say we've been very patient waiting for these issues to be resolved and the platform to mature.

The reason folks such as myself are resorting to setting our hair on fire to get attention is because everything else we have tried has failed and it really is the 11th hour for some of us with respect to UWP. I've recently had to let two staff members go because we our bleeding money.

Around the 2005 time frame, Windows technology was in the mix for some 70+% of the higher end music production at the time and was a sure bet for most software projects. Today the Windows share is probably well under 30% due to the fact that it's still using Win32 tech (not Winforms, not WPF, and especially not UWP). The UWP slice of high end music production is zero.

UWP is miles ahead of Win32 on many levels. The UWP vision is 100% valid. Being able to compile C# to native code is a huge win. Yet the UWP MIDI stack has been seriously broken since its release in 2014. The UWP camera capture API's have issues. The UWP Audio API's have issues. The UWP file system API's have issues. The UWP threading model has issues, etc., etc. Most of the problems can be worked around, but some are show stoppers. Problems don't get resolved because external devs get pushed back excessively. Why? Sadly, the real answer is incompetence on the part of a handful of Microsoft PM's that just happen to be in a critical role and upper management that is out of touch with reality in key areas.

Not having F# for MIDI transforms gives us just one other alternative, writing a Linq provider for C#. We might get the job done faster by joining the F# team to resolve their issues.

Apple makes a crazy amount of money from its store and as cool as Azure is, the mind share that it will generate is miniscule in comparison. In other words, the Microsoft Store is more important than Azure as a company focus for the long game.

If hair set on fire (on the part of external developers) doesn't lead to a solution to these problems, I think we all know how this story ends.

This will be my last post in any F# github area in the absence of UWP support because my hair is starting to fizzle and I've grown weary of having to be so emphatic.

Fingers crossed for all of us ...

[OnurGumus]

On the meanwhile, Google sponsoring the first F# conference in San Francisco

[OnurGumus]

@Noemata I understand your pain especially after reading the comments under FL Mobile studio It says: "MIDI Controllers: If your MIDI controller has stopped working, please remove Microsoft Update (KB4025342). This should restore MIDI operations until we can fix the issue."

[pjmlp]

@OnurGumus

I removed my comment as it did not make any sense and looked a bit aggressive, sorry about it.

Regarding your suggestion, one possible UWP use case that I can abstractly talk about, would be at customer site that is wondering about solutions for their shiny new Windows 10 hybrid tablet/laptops.

To sell them the story of using F# to their developers, as an external consultant, it has to match their already existing C# workflows, anything that requires extra effort and isn't officially supported won't be accepted.

Proposing something like Fable would also not be accepted, because then we would be in the domain of Web applications, in which case they aren't using anything .NET related.

[forki]

Fable doesn't automatically equal "web". That's just not true. Fable allows server side via node.js, desktop via electron and UWP, Android and iOS via react-native. These things are Javascript driven but not "web". I think you dismissed it way too early.

Am 18.08.2017 20:32 schrieb "pjmlp" notifications@github.com:

@OnurGumus https://github.com/onurgumus

I removed my comment as it did not make any sense and looked a bit aggressive, sorry about it.

Regarding your suggestion, one possible UWP use case that I can abstractly talk about, would be at customer site that is wondering about solutions for their shiny new Windows 10 hybrid tablet/laptops.

To sell them the story of using F# to their developers, as an external consultant, it has to match their already existing C# workflows, anything that requires extra effort and isn't officially supported won't be accepted.

Proposing something like Fable would also not be accepted, because then we would be in the domain of Web applications, in which case they aren't using anything .NET related.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-323428772, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNEI2LOPqQi0mqOBDEgsdgT5R8Iy1ks5sZdingaJpZM4IN6Rd .

[pjmlp]

@forki

I dismissed Fable, because for the customers that I work with, no such sort of transpilers is allowed.

Only platform languages directly supported by the respective SDK are allowed by their IT departments.

[forki]

That is very much a matter of definition. But I'm not arguing with you. You can always define it in a way that hurts yourself most.

Am 18.08.2017 22:02 schrieb "pjmlp" notifications@github.com:

@forki https://github.com/forki

I dismissed Fable, because for the customers that I work with, no such sort of transpilers is allowed.

Only platform languages directly supported by the respective SDK are allowed by their IT departments.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-323448160, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNApNkop0J2oFwnkllOn2iH6VNg2Dks5sZe3XgaJpZM4IN6Rd .

[KevinRansom]

Fable is very cool indeed. We on the VisualFSharp team are very excited to see this effort and the quality of the work going on this space.

[ghost]

React is a poor recommendation for any small company, and I found an article that sums it up well here: https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2

TL;DR

If your product is built on React, acquiring you means losing these rights, and this is something they are probably not prepared to do.

Basically, potential buyers will not touch you with a ten-foot pole, if buying you means they have to surrender their rights to ever sue Facebook for patent infringement.

Not only that, the licensing is far from optimal.

TL;DR

Projects at the Apache Software Foundation can no longer use dependencies that are distributed under Facebook’s “BSD+Patents” license, including React.

[forki]

Yes that license is problematic. But not for small companies.

Am 20.08.2017 3:00 vorm. schrieb "Roger" notifications@github.com:

React is a poor recommendation for any small company, and I found an article that sums it up well here: https://medium.com/@raulk/if- youre-a-startup-you-should-not-use-react-reflecting-on- the-bsd-patents-license-b049d4a67dd2

TL;DR

If your product is built on React, acquiring you means losing these rights, and this is something they are probably not prepared to do.

Basically, potential buyers will not touch you with a ten-foot pole, if buying you means they have to surrender their rights to ever sue Facebook for patent infringement.

Not only that, the licensing is far from optimal https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2 .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-323556588, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNP-5IwZaUht3V_M3haIY6OkdDlbtks5sZ4U-gaJpZM4IN6Rd .

[OnurGumus]

I think it's now semi official that UWP is dead as Office and Windbg appeared in store. So just develop a wpf app with desktop bridge and the problem's solved.

[charlesroddie]

@OnurGumus Your post does not make sense. UWP was never the right technology for applications that are desktop only. Only an insane company would take a huge application designed for desktops and spend billions to port it to a feature limited mobile-friendly framework. The point of UWP is to enable targeting mobile and desktop platforms simultaneously (either within the Windows world or more likely now via Xamarin).

[forki]

targeting mobile and desktop platforms simultaneously

Which is questionable in itself. Even targeting the whole mobile palette like RN does is challenging. Desktop is completely different UI/UX and even harder to unify.

[charlesroddie]

Clearly what works on an iPad will also work well on a Surface or other touch-enabled device running a desktop OS. Usually tablet apps can be made to work fine with mouse and keyboard too. For small companies, developing separate mobile and desktop apps is usually not feasible. Even from large companies, there are a number of apps that bridge the gap successfully (e.g. Slack, Maps), and many examples of apps that are missing on desktop where users are complaining about having to go to a website (e.g. a number of O365 apps).

Overall the people that need this technology have considered platform choice extensively before deciding that they need it, so casually suggesting that they make desktop apps instead or migrate to a javascript framework without an extremely comprehensive case (including target platforms, performance, code structure, 3rd party libraries, etc.) is just not going to work.

[vitordelucca]

@OnurGumus that's not true at all. With latest FCU update, there's 4k~ UWP APIs added (plus, 19k APIs on UWP .NET 6.0)

[OnurGumus]

@vitorgrs if I am wrong, why Microsoft is not making use of it? Did you know that 4k API you are referring isn't supported on Windows Mobile?

Finally we call it uwp for other devices. Currently devices that use uwp and that are not desktop is like 0.01% of the market. Windows Mobile => dead, not being manufactured or sold. Surface Hub => haven't heard anyone using it, not sure even being sold. Holo lens =>Same as above Xbox => there are some minor amount users, but almost no one uses uwp Raspberry pi=> no one uses uwp there either. So all we have is desktop.

We will see, but to me I predict Microsoft will just use windows store as an automatic updater and that's all. And for that, I would just stick to chocolatey myself.

Lastly when it comes to F# support Microsoft is proven to be a liar

See the post https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/9110134-f-support-in-net-native-for-uwp It says working on it right? Now see the comments here https://blogs.msdn.microsoft.com/dotnet/2017/08/25/uwp-net-standard-2-0-preview/

Immo Landwerth [MSFT] AFAIK there are no plans to add support for full tail call optimization

So you see, there are no plans to support it. Isn't this blatantly lying? And that's why for developers Microsoft is going down the hill for the last decade. It's not a company you can trust. They just have top notch engineers and dishonest decision takers.

[psfblair]

As a HoloLens developer, I must object. UWP is the way to create HoloLens applications and get them on the Windows Store. Microsoft is betting big on HoloLens, they have given no indication that there will be any other significant way to create HoloLens applications, and they wouldn't have introduced a major new device supporting only technology that they intend to kill. As a HoloLens developer, I have been completely stymied by this issue, which is a blocker for developing HoloLens apps in F#.

Unity,which is by far the tool in most widespread use for HoloLens, generates in its compilation step a UWP Visual Studio solution which must be compiled separately in a second step. As a result, I don't see that the desktop to UWP bridge is a viable solution. (Unity also has an IL to CPP back end which fails with F# owing to its inability to support deeply nested generics; there is no indication they intend to address this issue any time soon despite F# support being their fifth most-requested feature.)

Some months ago on this thread @dsyme suggested using an ILDASM/grep/ILASM cycle to removing "tail."calls from FSharp.Core in the appropriate profile. Unfortunately I've had to focus on developing my HoloLens application and haven't been able to pursue this lead. (I'm also not familiar with these tools; if I can get back to this it would be helpful if I could find out how to obtain and learn about them.)

[charlesroddie]

@OnurGumus They have no plans to support tail call optimization. That is irrelevant to getting F# working (See Don Syme's post here 11 July 2016). Hopefully this has been communicated to the .net native team.

[forki]

Ok. So if it's not tail calls. Then what is seriously left that can't be done?

Am 02.09.2017 10:33 nachm. schrieb "charlesroddie" <notifications@github.com

:

@OnurGumus https://github.com/onurgumus They have no plans to support tail call optimization. That is irrelevant to getting F# working (See Don Syme's post here 11 July 2016). Hopefully this has been communicated to the .net native team.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-326767891, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNNzN-eXCsgIzx4-5qIWNs9sqGcLQks5sebuJgaJpZM4IN6Rd .

[charlesroddie]

@forki The only serious issue looks like nested generics. See the first post: "A bug where a 17 layer-deep nested generic type (eg. A<B<C<D<…>>>>) would cause .NET Native to infer the type was infinitely deep and fail". Or @MattWhilden 's comment about a printf test giving this type of code.

This also was the problem in Unity that @psfblair came up against: "IL2CPP limits the recursion depth of generics to 7 levels currently... Often with F# code we see deeply nested generic type and method hierarchies which hit this limit."

Assuming that 17 is .NET Native's unlucky number, that is much better than IL2CPP's unlucky number 7. It may be very manageable to work around this limitation. So this problem doesn't necessarily have to be fixed to get F# working either.

If it does need to be done properly, @dsyme knows how.

[KevinRansom]

@charlesroddie I'm pretty sure the nested generics got fixed.

[forki]

So what's left? I'm seriously wondering.

[zpodlovics]

I just wondering: Is F# type checking decidable ? Is .NET Native type checking decidable ? Is it a solvable problem?

"Does the reduction from Section 5 apply to other languages like C# and Scala? No. Both of them adopted the recursive–expansive restriction of (Viroli 2000), as recommended by (Kennedy and Pierce 2007). Roughly, this restriction is a syntactic check that succeeds if and only if our Turing tapes are bounded. For bounded tapes, the halting problem is decidable."

Radu Grigore: Java Generics are Turing Complete https://arxiv.org/abs/1605.05274 https://gist.github.com/rgrig/b4cdaed3ed9a70dbdb6f158f14b57263

[21c-HK]

There may be technical issues that prevent .NET Native specifically from compiling valid F#/.NET AOT, but it is definitely a solvable problem. Xamarin already supported AOT-compilation of F# for some time now for their Android and iOS project templates. I don't understand why the UWP team does not just ask the Xamarin team how to do it, or why the UWP team does not just copy their implementation in the meantime since Xamarin was bought by Microsoft.

So this is not really a technical issue, but a political one, an issue of resource allocation / priorisation.

[forki]

again what technical issues? F# compiler emits IL - where exactly is the issue if it's not tailcalls?

[charlesroddie]

Now that tailcalls and generics are off the table, the remaining work looks small in scale. A few small fixes like internal enums and doing the ignoring of tailcalls and enabling compilation in Visual Studio.

[ShalokShalom]

@NumberByColors You might like to mention in your update section, that the .Net Native compiler is now open source: https://github.com/dotnet/corert

[realvictorprm]

Nice point. So can we do something there?

[abelbraaksma]

Just a stupid question, but I often wondered about this (and admittedly, I don't know too much about the details of .NET Native). It is already possible to precompile F# CIL code with NGEN. If that works, why doesn't it work with .NET Native? Or does NGEN skip some parts that .NET Native promises to address (apart from support for a larger set of platforms, I guess).

Just saying, if it is possible to NGEN, why isn't it (also) possible to compile with .NET Native?

[ShalokShalom]

Just to mention something: If this truly compiles F# into native code, a lot of people get interested into F-Sharp, since it means independence from .NET. I see less marketing about that aspect currently, which might be probably related due to the current state?

[cartermp]

Just as a point of distinction, corert is not the .NET Native compiler toolchain and runtime. .NET Native is still closed-source, proprietary technology.

NGEN is a separate technology as well.

That said, corert is likely to be the future of cross-platform native compilation of .NET code, and it has some very basic F# support already. Because it is open source, it’s relatively easy to contribute. The best way to start there is to create a few smoke tests to see what breaks, then address those issues one by one. Jan and others who maintain that repo will gladly help in such an effort.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: MatthiasSchuster notifications@github.com Sent: Saturday, September 23, 2017 5:16:28 PM To: Microsoft/visualfsharp Cc: Phillip Carter; Mention Subject: Re: [Microsoft/visualfsharp] F# Support in .NET Native and UWP (#1096)

Just to mention something: If this truly compiles F# into native code, A LOT of people get interested, since it means independence from .NET. Is see far too less marketing about that aspect yet, which might be probably related due to the current state. So, once release ready; Shout it out in the world.

F# is free. I see some OCaml guys coming, who would like a cleaner syntax.. without curly brackets. ;)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/visualfsharp/issues/1096#issuecomment-331677890, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGBEzg7hUgbiedRHdNx2vMM4PI_SNexAks5slZ9cgaJpZM4IN6Rd.

[ShalokShalom]

What is that? https://github.com/dotnet/corert/tree/master/src/Native And the description text says that: with the accompanying .NET Native compiler toolchain

The availability of different tools is the .Net ecosystem is truly diverse, which leads a newbie like me into some kind of confusion. :smile:

So, I can use CoreRT anyway to compile into native code? Also to Linux? Thats awesome.

@forki You might be interested into Qt Quick 2

It is possible to use Fable in order to develop applications for Android, iOS, macOS, Linux/BSD/Solaris (X11 and Wayland), Windows, Windows mobile, Blackberry 10 and a bunch of others, all with the same code.

They are inherently GPU accelerated and easy to code, can delight our eyes by smooth animations and scale to the used screen size automatically.

The implementation is used by a huge community, available in both, an open source and a closed source license, successfully used by thousands of developers and hundreds of companies.

Code the logic with F#, then transpile it into JS, import your .js into QML and use it to develop the GUI in a super easy, declarative JSON-like syntax :smiley:

You can run it in Qt Quick 2 itself and you can compile it thanks to the superb Qt Quick Compiler into C++.

The whole range of other Qt libraries is also available. :smile:

[abelbraaksma]

NGEN is a separate technology as well.

@cartermp, it is my understanding the NGEN creates binary images. I know these images are per-assembly (or per module, not sure) and thus they will still need the CLR. But since any lib including mscorlib can be NGEN'ed, essentially this means they can all become native. If you'd then have a linker, you could create a poor-man's .NET Native (at least for those parts not covered).

And taken from another perspective, JIT compiles to native, and if currently AoT (.NET Native / CoreRT) contains gaps in coverage, surely they can, at least temporarily, be replaced by whatever the more generic output of JIT is, right? Or am I oversimplifying here?

[mydogisbox]

@ShalokShalom See the "Architecture" section here: https://github.com/dotnet/corert/blob/master/Documentation/intro-to-corert.md From that I understand that the difference is that one is for the .Net Core runtime and the other is for the UWP runtime.

[ShalokShalom]

The whole situation all around the compiler state in the .Net world is highly confusing. So many different projects, I think it take both hands to count them all. :smile:

@mydogisbox Thanks for the link, very informative. :+1: