Why F# Needs .NET Native Support
There is some discussion about implementing .NET Native support for F# here -
I had a conversation with @xyziemba and @dotnet on Twitter recently about the .NET Native toolset and features. I…visualstudio.uservoice.com
and here -
There has been some discussion on the blog post http://blogs.msdn.com/b/dotnet/archive/2015/07/30/universal-windows…wpdev.uservoice.com
NOTE: If you agree with the content of this article, please vote on these two issues at their respective links!
As an F# power user, I have no doubt whatsoever that F# users need .NET Native support.
For instance, I’m attempting the crazy task of rebuilding the foundations of game programming with functional technology, and I have chosen F# as the tool with which to do it. However, the first objection I receive from people (at least, those who don’t know the details of my work) is that functional programming is too slow for soft real-time programming such as games.
Fortunately, I have already done a tremendous amount of work to falsify these objections. But if every time I advocate for game programming with F# I have to respond to the legitimate criticism of no .NET Native support, I am going to find the monumental task I’ve undertaken even more taxing.
FPWorks — Repository hosting the open-source Nu Game Engine and related projects.github.com
More generally, the wider community has also put in incredible effort to demonstrate the possibility and desirability of soft real-time programming with F# -
VisualFSharpPowerTools - Power commands for F# in Visual Studiogithub.com
Native Compilation — Extra Necessary for Functional Programming
If you’re familiar with the specialized optimizations that compilers like OCaml and SML can do for functional code, such as whole program optimization to deforest allocations and elide lambda chains (esp. with respect to F#’s computation expressions —
- you quickly realize the extra benefit that functional code can (and often must) achieve with compilation more specialized than RyuJIT will have the latency allowances to provide.
Additionally, by using F# and functional programming, we’ve already taken some risks as far as performance goes. To deprive us of native execution would compound that cost in a very painful way. While my code is mostly fast enough, sub-optimal code generation due to JIT pragmatics is not a reasonable bottleneck for games — be they pure functional or not!
And lastly, what would be the work-around for not having F# Native?
Do we build an F# to C# compiler? Being the language / hacker geeks we are, this frightful scenario could actually happen!
Or do we just go back to C# and try to forget all we’ve recently learned about computer science and writing truly modular programs? How ironic would it be if we have to return to C# just to write performant functional programs?
So, I would say that we, the F# community, effectively need .NET Native support. And just because our new language and projects don’t have an over-abundance of users doesn’t mean we’re unimportant. For there will be many more programmers who come after us than there ever has been of us, and they will not want to speak in our collapsing C-style languages or live in our indecipherable imperative code bases.