5 ms·

It's very good right now, especially with .NET core the new dotnet command, and VSCode's great support it's easier than ever to develop in F# on any platform.

hajile 8y ago
When is F# getting native compilation? MS has been promising it for years now. Last I heard, they still had zero progress toward handling tail calls.
- phillipcarter 8y ago
  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 8y ago
    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?
    - wtetzner 8y ago
      If you're not interested in .NET or the CLR, what is it about F# that interests you over OCaml?
      - wyoung2 8y ago
        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 8y ago
        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.
    - phillipcarter 8y ago
      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/ http://fable.io/
      - wyoung2 8y ago
        > 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.

hajile 8y ago

When is F# getting native compilation? MS has been promising it for years now. Last I heard, they still had zero progress toward handling tail calls.

phillipcarter 8y ago
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 8y ago
  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?
  - wtetzner 8y ago
    If you're not interested in .NET or the CLR, what is it about F# that interests you over OCaml?
    - wyoung2 8y ago
      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 8y ago
      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.
  - phillipcarter 8y ago
    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/ http://fable.io/
    - wyoung2 8y ago
      > 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.