4 ms·

The last time I brought this up on HN, I received a comment [1] from one of the people who work on F# at Microsoft: F# is fundamentally a .NET language ... I

The last time I brought this up on HN, I received a comment [1] from one of the people who work on F# at Microsoft: F# is fundamentally a .NET language ... 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. I like F# a lot, and to me it comes across as something of a cleaner, more modern OCaml. I have zero interest in .NET and its toolchain, and I don't want the baggage of its runtime or VM. [1] https://news.ycombinator.com/item?id=17936732 https://news.ycombinator.com/item?id=17936732

kazinator 8y ago
It strikes me as nonsense. Let's take the paragraph and replace "F#" with "C", ".NET" with "PDP-11", and "Core" with "V6 Unix". Come on, surely you can make a non-.NET dialect of F#. Sure, not every .NET F# program will be portable to it. There must be some considerable abstraction in F# that isn't tied to .NET.
- bonesss 8y ago
  Can you make a language that looks like F# and compiles? Sure. Can you make F# the language meaningful on other VMs? Not really, as F# is a deep, deep, .Net language. This isn't about abstraction or syntax, it's that every concept, feature, and element of the toolchain bases itself on .Net capabilities and considerations. From referencing libraries, to scripting, to type generation at specific points in the compile cycle to support Type Providers... Async computation blocks... Remember, F# came from MS research based on the established working .Net framework, and was tighly tied to fundamental framework improvements (like generics and dynamics). It was built by hardcore .Netters, it's the first "true" .Net language, and it bases major language features on deep-down .Net capabilites not found in other VMs. The point of the quote is that if you were to try this, at best you'd get "OCaml Over There", not "F#", since F# without .Net is "OCaml". It's not the syntax, it's the deeply intertwined nature of everything else.
  - vram22 8y ago
    >Remember, F# came from MS research based on the established working .Net framework, and was tighly tied to fundamental framework improvements (like generics and dynamics). It was built by hardcore .Netters, it's the first "true" .Net language, What are "dynamics" in this context? >and it bases major language features on deep-down .Net capabilites not found in other VMs. Can you give some examples of that?
    - profquail 8y ago
      “Dynamic” in GP’s answer is referencing .NET’s support for dynamic typing (which works in both C# and F#): https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
      - vram22 8y ago
        Thanks, will check that out.
      - kazinator 8y ago
        That just looks earth-shatteringly non-portable; it cannot possibly exist anywhere but .NET.
        loeg 8y ago
        Ahem. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/multiple-language-support.html#invokedynamic https://docs.oracle.com/javase/8/docs/technotes/guides/vm/mu...
- sparkie 8y ago
  F# without the .NET platform is essentially OCaml. The differences between the two languages are primarily in the way it integrates with the .NET platform and many assumptions on it. If you wanted something similar on say, the JVM, starting from OCaml, you would make many different design choices and the result would be a very different language.
  - kazinator 8y ago
    So F# is the name of an OCaml implementation for .NET, which adds nothing but very .NET-specific extensions that don't make sense anywhere else?
    - sparkie 8y ago
      Mostly. It does add some novel new features which could be reused on other platforms, but many of the features are tightly linked to the .NET base class library, and would not translate cleanly over to other platforms (certainly possible to simulate them, but you would probably want something which integrates better with your VM) For example, the whole type system is based on .NETs type system. interfaces, subtyping and generics, properties and indexed properties, which are quite different on the JVM and other platforms. F# usually relies on having attributes (annotations in Java) for compatibility with other .NET languages like C# where certain features did not fit into the OCaml syntax and semantics cleanly. These also wouldn't transfer over to other platforms very well. Some features which F# has that could transfer over to other platforms include measure types, active patterns, and type providers. I believe some of these have already made it to other languages. Gosu, for example, on the JVM had a feature similar to type providers before F# got them, so you could argue that F# borrowed that feature.
- piaste 8y ago
  https://fable.io/repl/ https://fable.io/repl/ This is a F# -> Javascript compiler and environment, itself running in your browser (in Javascript, obviously). https://github.com/kjnilsson/fez https://github.com/kjnilsson/fez This is a project running F# on BEAM (Erlang). So yes, of course you _can_ write a compiler from F# to whatever platform you choose. It's just a really major effort, in no small part because F# is a way, _way_ higher-level language than C (you'll remember 'worse is better' - a big deal with C is that it's easy to write a compiler for).
  - kazinator 8y ago
    > a big deal with C is that it's easy to write a compiler for We are still feverishly at it in 2018 and there is no end in sight. > It's just a really major effort That is neither here nor there.
kyleperik 8y ago
Thanks, I think we find ourselves in the same boat. To everyone else - maybe I should have asked a better question, but it's quite clear to me now that people are in fact using this in production. That's great. My only question now is, what is Microsoft's strategy here? There's no money flow with .net core as far as I know, so why put in the effort?
- jerryluc 8y ago
  Azure. Microsoft revolves around Azure these days, if they can provide a better dev experience that leads to more people using Azure they're happy to spend money on it.
  - oblio 8y ago
    Not just Azure, cloud. Office can be extended with .NET. And Office is now Office 365. Plus, Microsoft wants to get back in the game on mobile, so they need at least a platform, if not an OS. If they can put .NET reliably on top of Linux, Android, iOS, they can probably find ways to monetize that.
- bonesss 8y ago
  Their strategy is to make bank. Traditionally MS was laughed out of vast swaths of academia, research, and Enterprise solutions. Now, they're making ever more bank off of Azure, and want to get their products deeper into those markets where being Linux friendly, cross-platform, and all the rest are "must have" features. That's big money, and future growth. At the same time: their current breed of engineers also struggles with some of the historic windows nonsense, and it's becoming ever less profitable to maintain. So it makes sense even for MS to transition a bit away from legacy MS. SQL server runs on Linux now, MS hosts Kubernetes cluters and has Linux bundled in Windows, and Azure scaling is always cheaper when not paying OS licensing fees. MS stands to win a lot by having a relevant development platform, MS stands to win a lot being the tool provider of choice for cloud development, MS stands to win on cloud hosting and growth, and MS stands to win a lot with upselling to captive cloud customers (BI, BizTalk, OMS, Analytics, etc). .Net Core is the free razor, everything else are the high-margin blades :)

kazinator 8y ago

It strikes me as nonsense. Let's take the paragraph and replace "F#" with "C", ".NET" with "PDP-11", and "Core" with "V6 Unix". Come on, surely you can make a non-.NET dialect of F#. Sure, not every .NET F# program will be portable to it. There must be some considerable abstraction in F# that isn't tied to .NET.

bonesss 8y ago
Can you make a language that looks like F# and compiles? Sure. Can you make F# the language meaningful on other VMs? Not really, as F# is a deep, deep, .Net language. This isn't about abstraction or syntax, it's that every concept, feature, and element of the toolchain bases itself on .Net capabilities and considerations. From referencing libraries, to scripting, to type generation at specific points in the compile cycle to support Type Providers... Async computation blocks... Remember, F# came from MS research based on the established working .Net framework, and was tighly tied to fundamental framework improvements (like generics and dynamics). It was built by hardcore .Netters, it's the first "true" .Net language, and it bases major language features on deep-down .Net capabilites not found in other VMs. The point of the quote is that if you were to try this, at best you'd get "OCaml Over There", not "F#", since F# without .Net is "OCaml". It's not the syntax, it's the deeply intertwined nature of everything else.
- vram22 8y ago
  >Remember, F# came from MS research based on the established working .Net framework, and was tighly tied to fundamental framework improvements (like generics and dynamics). It was built by hardcore .Netters, it's the first "true" .Net language, What are "dynamics" in this context? >and it bases major language features on deep-down .Net capabilites not found in other VMs. Can you give some examples of that?
  - profquail 8y ago
    “Dynamic” in GP’s answer is referencing .NET’s support for dynamic typing (which works in both C# and F#): https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/types/using-type-dynamic https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
    - vram22 8y ago
      Thanks, will check that out.
    - kazinator 8y ago
      That just looks earth-shatteringly non-portable; it cannot possibly exist anywhere but .NET.
      - loeg 8y ago
        Ahem. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/multiple-language-support.html#invokedynamic https://docs.oracle.com/javase/8/docs/technotes/guides/vm/mu...
sparkie 8y ago
F# without the .NET platform is essentially OCaml. The differences between the two languages are primarily in the way it integrates with the .NET platform and many assumptions on it. If you wanted something similar on say, the JVM, starting from OCaml, you would make many different design choices and the result would be a very different language.
- kazinator 8y ago
  So F# is the name of an OCaml implementation for .NET, which adds nothing but very .NET-specific extensions that don't make sense anywhere else?
  - sparkie 8y ago
    Mostly. It does add some novel new features which could be reused on other platforms, but many of the features are tightly linked to the .NET base class library, and would not translate cleanly over to other platforms (certainly possible to simulate them, but you would probably want something which integrates better with your VM) For example, the whole type system is based on .NETs type system. interfaces, subtyping and generics, properties and indexed properties, which are quite different on the JVM and other platforms. F# usually relies on having attributes (annotations in Java) for compatibility with other .NET languages like C# where certain features did not fit into the OCaml syntax and semantics cleanly. These also wouldn't transfer over to other platforms very well. Some features which F# has that could transfer over to other platforms include measure types, active patterns, and type providers. I believe some of these have already made it to other languages. Gosu, for example, on the JVM had a feature similar to type providers before F# got them, so you could argue that F# borrowed that feature.
piaste 8y ago
https://fable.io/repl/ https://fable.io/repl/ This is a F# -> Javascript compiler and environment, itself running in your browser (in Javascript, obviously). https://github.com/kjnilsson/fez https://github.com/kjnilsson/fez This is a project running F# on BEAM (Erlang). So yes, of course you _can_ write a compiler from F# to whatever platform you choose. It's just a really major effort, in no small part because F# is a way, _way_ higher-level language than C (you'll remember 'worse is better' - a big deal with C is that it's easy to write a compiler for).
- kazinator 8y ago
  > a big deal with C is that it's easy to write a compiler for We are still feverishly at it in 2018 and there is no end in sight. > It's just a really major effort That is neither here nor there.

kyleperik 8y ago

Thanks, I think we find ourselves in the same boat. To everyone else - maybe I should have asked a better question, but it's quite clear to me now that people are in fact using this in production. That's great. My only question now is, what is Microsoft's strategy here? There's no money flow with .net core as far as I know, so why put in the effort?

jerryluc 8y ago
Azure. Microsoft revolves around Azure these days, if they can provide a better dev experience that leads to more people using Azure they're happy to spend money on it.
- oblio 8y ago
  Not just Azure, cloud. Office can be extended with .NET. And Office is now Office 365. Plus, Microsoft wants to get back in the game on mobile, so they need at least a platform, if not an OS. If they can put .NET reliably on top of Linux, Android, iOS, they can probably find ways to monetize that.
bonesss 8y ago
Their strategy is to make bank. Traditionally MS was laughed out of vast swaths of academia, research, and Enterprise solutions. Now, they're making ever more bank off of Azure, and want to get their products deeper into those markets where being Linux friendly, cross-platform, and all the rest are "must have" features. That's big money, and future growth. At the same time: their current breed of engineers also struggles with some of the historic windows nonsense, and it's becoming ever less profitable to maintain. So it makes sense even for MS to transition a bit away from legacy MS. SQL server runs on Linux now, MS hosts Kubernetes cluters and has Linux bundled in Windows, and Azure scaling is always cheaper when not paying OS licensing fees. MS stands to win a lot by having a relevant development platform, MS stands to win a lot being the tool provider of choice for cloud development, MS stands to win on cloud hosting and growth, and MS stands to win a lot with upselling to captive cloud customers (BI, BizTalk, OMS, Analytics, etc). .Net Core is the free razor, everything else are the high-margin blades :)