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