[phillipcarter]

Note: there's a very big difference between "native compilation" and the product known as ".NET Native".

.NET Native is a proprietary, Windows-only backend compiler toolchain for statically linking and tree-shaking compiled IL, used only for UWP apps on Windows 10 devices. It is this toolchain that does not support F#.

Beyond that, there are no toolchains for compiling to a single, native binary that are a shipping part of the .NET product.

We are not prioritizing .NET Native for F# at this time (from the F# team perspective), as we feel that .NET Core gives us more reach for F#.

[atombender]

As someone who's interested in F#, but has zero interest in ".NET", I hope for F# to someday become available as an independent language with native compilation and minimal runtime -- no Mono, no CLR, native platform support on Linux and Mac, and so on. But it sounds like that's not the direction things are going in?

[phillipcarter]

Although there are counter-examples of this (F# on the web via Fable[0] is one), F# is fundamentally a .NET language. There were many decisions in its design that are a direct result of running on .NET:

* Object programming with F# is based on .NET objects

* Generics in F# are based on .NET generics

* Reflection-based features are based on .NET reflection

* Structs in F# are based on .NET value types

* Newer features in F# 4.5 are based on newer .NET features

* Forthcoming nullability features will be based on nullability annotations in .NET metadata

It's impossible to divorce the two, even if the target runtime environment is not necessary a .NET runtime. Those other environments inherent language design decisions made with .NET as a target runtime. The .NET runtime with .NET Core is indeed minimal, is natively supported just about everywhere, and was built with cross-platform in mind. F# is a part of this, for better or worse.

[0]: http://fable.io/

[wyoung2]

> It’s impossible to divorce the two

It would surely be a lot of work, but “impossible?”

I think you’re missing a couple of major tricks by not doing a native code compiler for F#:

1. Now that Moore’s Law^H^H^HBusiness Rule has run dry, we can’t continue to just pile up the abstraction layers. Some sage once said that every problem in CS can be solved by adding another layer of abstraction, but there’s one that can’t: make it faster without buying more hardware. Given how popular FP is among the quants, a field often going after microsecond latencies, I’d think this would be a constant refrain from potential customers.

2. I don’t want to ship a dotnet runtime to my customers. Just this morning, I had to update a customer accessible only via a highly restrictive VPN, where they haven’t given my server DNS access, much less unfiiltered Internet access. Everything I ship to them has to be scp’d to the server over the VPN. I really really don’t want to send each such customer hundreds of megs of dotnet runtime stuff, then be forced to work around the failure of “dotnet restore”, so I’m going right back to C++ so I can get native binaries.

Hundreds of megs might be charitable. I just did a “du” of /usr/local/share/dotnet on a workstation here and got 1.4 GB. Presumably that compresses down to mere hundreds of megs. Contrast the size of a “Hello world” binary, which I’d expect to be under 10 kB.

I want to like F# on dotnet, but you’re making it hard for me to use it in practice.

[phillipcarter]

I'm not sure what your environment looks like, but the .NET runtime is not even close to hundreds of MB in size. Unless you distributed a large amount of resources in your self-contained distribution (e.g., many massive images) would it come close to approaching that size.

A development environment includes the .NET SDK, shared framework, and NuGet packages. So that's going to be large in size. But you should never distribute the SDK with a published application. That's pushing a development environment onto a production machine.

[wyoung2]

Yes, you're right, I shouldn't use the development tree for my comparison here. The runtime-only .NET Core 2.1.3 installer for my platform is only (cough) 26.3 MB.

If you then try to get that lower by using self-contained builds, you can only get "Hello, world!" down to about 20 MB:

    $ dotnet new console --language f# -n hello
    $ cd hello
    ...add <RuntimeIdentifier>osx.10.13-x64</RuntimeIdentifier> to fsproj
    $ dotnet publish --self-contained -c release
    $ cd bin/release/netcoreapp2.1/osx.10.13-x64/publish
    $ rm -r ?? ??-?? zh-*                 # nuke i18n
    $ tar -cvJf ~/Desktop/hello.tar.xz .

You'll notice that I'm giving you the benefit of high compression here. The unpacked tree is 70 MB!

The equivalent in C++ is 3.3 kB.

I'm not expecting miracles. As I said, I'd be happy with "only" a 3x ballooning here, roughly commensurate with the coding efficiency benefit. That's fair.

[phillipcarter]

Just to clarify my other point, it is strictly impossible to undo the .NET-influenced language design decisions of F# without either making massively breaking changes, or writing a brand-new language with F#-like syntax and F#-like semantics.

[wtetzner]

If you're not interested in .NET or the CLR, what is it about F# that interests you over OCaml?

[wyoung2]

For me, the attractions of F# over OCaml are:

1. Cleaner syntax. F# shows that we can do away with a lot of the visual noise in OCaml. I’m no particular fan of white space scoping, but I also don’t mind it.

2. Much better thought out standard library. The OCaml standard library was clearly accreted over long periods, with no strong designer making hard choices about naming and such. The example that keeps coming back to me is “big_int” vs all the other integer data types.

I believe #2 is what the OP meant by “minimal runtime.” A minimal F# will still need a good set of data types, a string library, etc.

[atombender]

Pretty much what wyoung2 said. F# feels much more modern than OCaml, with fewer weird warts. I don't know much about .NET, other than that I don't want it, just like I don't want the JVM.