7 ms·

What's New in F# 4.1? [video]

131 points by LyalinDotCom 10y ago

ainar-g 10y ago
I feel like the title lacks the "[video]" tag. Unless I've missed the text version somewhere on that page.
- LyalinDotCom 10y ago
  good point! sorry for not adding it right away
LyalinDotCom 10y ago
Also for those that rather read the blog post, check this out, A Peek into F# 4.1: https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-into-f-4-1/ https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-in...
fromscala11 10y ago
We need HKT. F#. Cmon... I love F# but seriosly...
- TIHan 10y ago
  Do we really need them?
  - justneedvodka 10y ago
    No. There's a difference between needs and wants.
    - seanparsons 10y ago
      Well if you don't think a modern FP language needs higher kinded types you probably do need vodka.
- KurtMueller 10y ago
  What's hkt?
  - thijsvandien 10y ago
    Higher-Kinded Types "With higher-kinded types [...] type operators can be parameterized by other type operators. Java doesn’t support higher-kinded types, but, if it did, you would be able to write something like this:" class GraphSearch<T> { T<Node> frontier; } Source: https://www.stephanboyer.com/post/115/higher-rank-and-higher-kinded-types https://www.stephanboyer.com/post/115/higher-rank-and-higher...
- Rickasaurus 10y ago
  We're working on Type Classes. It seems like HKTs (or anything like them) are going to be hard without diverging in a huge way from the rest of the .NET ecosystem.
  - KirinDave 10y ago
    I really think Type Classes will address 90% of what people want without requiring deep hackery. The solutions we have with class dispatch right now are workable but awkward.
  - jhomedall 10y ago
    That's fantastic news! I currently use Scala for most of my personal development, but having type classes would make F# attractive enough for me to switch over. I much prefer the cleaner syntax of F#. Losing HKT would be a shame, but that's a trade-off I would be willing to make.
    - willtim 10y ago
      Scala has never properly supported HKTs though. When I last tried it, there were multiple open issues, e.g. the partial application of type parameters. So I really don't buy the argument that Scala scores a point over F# due to HKTs. If you want HKTs, use Haskell.
      - daxfohl 10y ago
        It scores at least 0.7 points though. That said, it loses points elsewhere (as do all languages).
  - daxfohl 10y ago
    I'm curious, will Type Classes enable http://www.sparxeng.com/blog/software/an-example-of-what-higher-kinded-types-could-make-possible-in-c http://www.sparxeng.com/blog/software/an-example-of-what-hig... without needing HKT?
- tpetricek 10y ago
  Not only we do not need HKT, we also do not need Profunctor Optics.
  - purity_resigns 10y ago
    They're a great way to massively slow down both your build and runtime by an order of magnitude. I work with Purescript on a daily basis and don't see it as anything other than an anti-feature that allows for masturbatory FP.
  - KirinDave 10y ago
    F# and its spirit animal OCaml are really great precisely because of this attitude. They're really good at saying "No" to things that offer at best incremental improvements at the cost of significant complexity. "Profunctor Optics" is a great example. Cool paper, but no thanks.
    - runT1ME 10y ago
      Higher kinded types reduce complexity in the same way generics reduce code complexity. If you think one makes things simpler but not the other, I would assume you're not familiar with it? Do you have examples of why it would add significant complexity? I use them constantly and it really simplifies my code a lot! Also, I don't believe 'profunctor optics' is a paper, I think it's just one (interesting) implementation of optics, which are useful in any language that encourages immutability.
      - KirinDave 10y ago
        The complexity that HKT brings to F# is not just conceptual. It needs to exist in the CLR which will bring implementation tradeoffs. "Cool paper but no thanks" is a saying for when people come to you with an extremely new technique and want you to incorporate it at the language level with very little proofing in the field. "Profunctor optics" is the a description of how profunctors encode lenses and similar structures. I am aware. I also think that technique can cook in Haskell land for a few more years before non-research projects should uptake it.
- phillipcarter 10y ago
  Awkward person who was in the video here The issue you're looking for (since an ask for HKTs typically means that Typeclasses are the ideal feature) is here: https://github.com/fsharp/fslang-suggestions/issues/243 https://github.com/fsharp/fslang-suggestions/issues/243 Please leave opinions, commentary, and vote if this is something you want! F# language design is done completely in the open, including motivation for features. Thanks!
alkonaut 10y ago
Wait what, doing this as an alias type ProductId = ProductId of int Meant it allocated an instance on the heap for it before 4.1? Wow.
- edgyswingset 10y ago
  That isn't actually an alias. That is constructing a single-case discriminated union. DUs are compiled into classes and have a few things automatic equality. Generally speaking, it's better to use Units of Measure[0] when you want some compile-time semantics around numeric literals, as these don't incur the performance penalty of creating a class. [0]: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/units-of-measure https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang...
  - alkonaut 10y ago
    Yeah I realize there are more efficient aliases, but even so - just defaulting immutable data structures with only primitive types in them to cretae reference types feels like a massive foot gun performance wise. I couldn't imagine doing C# without value types, so for F# where things are usually more immutable, it has to be painful if e.g. a normal point(x,y) record is a class...
    - justneedvodka 10y ago
      You could use a struct, record, or tuple for a point. I've done all of these before.
      - alkonaut 10y ago
        Yes, and now they can be done right (as CLR structs)! It's just odd that this took until now. I suppose it just shows that those of us that are using .NET to do "C++ work" (always CPU and GC bound, almost never IO bound) are pretty few...
stcredzero 10y ago
I'm interested in .NET ecosystem languages, as well as functional programming. How is the parsing and meta-programming toolset? How easy or hard would it be for me to implement a subset of F# that only allows pure functions?
- drbradley 10y ago
  Very strong on the parsing front - FSharp.Data contains parsers and type providers for a variety of common formats and FParsec is a mature parser combinators library.
  - VoiceOfWisdom 10y ago
    FParsec is fantastic. I have implemented a parser that supports a indentation based language in it. FParsec makes it very productive, and very fun.
    - mamcx 10y ago
      Is published? I have tried to use FParsec before for the same kind of language and failed.
      - VoiceOfWisdom 10y ago
        Its currently in a private bitbucket repo. I can give you the parser though, MIT licensed. ParserUtils is where maybeIndented and indented are. They make indentation just work. There currently overzealous with backtracking though, makes errors kinda shit. Working on that at somepoint. https://gist.github.com/xavierzwirtz/99479a11f1eefd3215467f7ea26b5c46 https://gist.github.com/xavierzwirtz/99479a11f1eefd3215467f7...
        mamcx 10y ago
        Ok, thanks. But this not look more easy than just do it as TopDown Parser. But I don't know your language so it maybe have provided you with some benefits more than just lines of code?
tpetricek 10y ago
While it is great to see all those new features appearing in F# 4.1, the video gives a very narrow perspective on "what is new in F#" - it is a video about new language features in 4.1 and so this is to be expected - but if I was to list "what is new in F# in 2016", large portion of the list would include recent community contributions. Three recent projects are: * http://fable.io http://fable.io, which is a modern F# to JavaScript compiler that lets you build Elm-style apps, access React and all that fun * http://ionide.io http://ionide.io which is an F# integration for Atom and VS Code that is doing amazing work towards bringing F# to a fully cross-platform ecosystem * http://notebooks.azure.com http://notebooks.azure.com which is (very new) free Microsoft-hosted Jupyter Notebook service that provides support for the usual suspects (R and Python), but also ships with great F# support out-of-the-box In other words, I think the language is way ahead of the libraries and tooling - there is so much more that can be done (and is being done) using F# as-is!
- partisan 10y ago
  VS Code and Ionide work really well together. There are some slight issues like the loss of syntax highlighting in certain cases, but that is a really small issue. I am using this combination on a GalliumOS chromebook and it works out of the box in like 10 or 15 minutes: - install VSCode and then Ionide - install .net core - install mono (i believe ionide still uses mono) - install node and npm and then yeoman - install the aspnet generator for yo - "yo aspnet" will give the option to generate a working ASP.NET F# website
  - mamcx 10y ago
    > VS Code and Ionide work really well together Not in my experience. Never since it appear the setup have worked for me, not even once. I try again last week. I need to copy-paste the .sh script from github because the one it generate was wrong. P.D: I don' use yeoman. NPM bloat is not my style: I follow the MS tutorial: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-vscode https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...
    - 10y ago
jackmott 10y ago
Some nice performance improvements in the core libs and compiler as well.
grayrest 10y ago
So, I've been making a slightly more concerted effort to pick up F# because I've always liked F# and .Net core and Fable means that I might actually get to run it at work without the non-starter of switching stuff over to windows servers. Excellent. The main holdup is that the build/packaging situation is disastrous. Most stuff still relies on Mono, which is fine, but trying to get things running on core quickly runs you into articles that assume you know exactly what you're doing and how all the pieces fit together, which is also fine. What's not fine is that the base task of wanting to download existing packages and run the result doesn't have a simple solution. The base .net core install comes with a project.json solution, which seems completely sane to me, but apparently that's deprecated and not how to do things. Then there's Nuget which is a package repo but apparently not a package manager because it's supposed to be a VS extension but maybe it is in the next version because there's a shell. There's also msbuild and some variant of it for fsharp which is mostly opaque XML but can be managed using a project called forge, which seemed to kind of work for me but also seems very opaque. There's also paket which manages dependencies from nuget, there's also Fake which seems to be a Rake-like build system. I know I'm not the only one who's run into this. I've seen at least 4 other requests for help in various F# forums and everybody seems to pretty much shrug and say that they use VS. If one of the F# cognoscenti could write up simple instructions on how to set up a project and run it using VSCode and .Net core, I'd be grateful.
- phillipcarter 10y ago
  Awkward person in the video here... Let me see if I can clarify the landscape a bit here: .NET Core tooling support is still in absolute Preview. The runtime and libraries are stable, but the .NET Core SDK, MSBuild support for .NET Core, the project system in Visual Studio, etc. are all Preview support. Much of the F# community is waiting on .NET Core tooling stability to act, which they have every right to do. .NET Core tooling is still in Preview, and still changing rapidly. Using any cross-platform community tooling or libraries on .NET Core is likely going to be rough right now, and that's because the underlying tooling that the community needs to rely on is in Preview. F# support is still officially in alpha for .NET Core, a moniker we're pretty deliberate about because we don't want to "flip the switch" until everything is stable and compatible with existing code. Honestly, if the churn is painful for you, the best advice I can give at this point is to wait until the tooling for .NET Core stabilizes and becomes release-quality. Up until that point, there will still be churn.

131 points by LyalinDotCom 10y ago

ainar-g 10y ago

I feel like the title lacks the "[video]" tag. Unless I've missed the text version somewhere on that page.

LyalinDotCom 10y ago
good point! sorry for not adding it right away

LyalinDotCom 10y ago

Also for those that rather read the blog post, check this out, A Peek into F# 4.1: https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-into-f-4-1/ https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-in...

fromscala11 10y ago

We need HKT. F#. Cmon... I love F# but seriosly...

TIHan 10y ago
Do we really need them?
- justneedvodka 10y ago
  No. There's a difference between needs and wants.
  - seanparsons 10y ago
    Well if you don't think a modern FP language needs higher kinded types you probably do need vodka.
KurtMueller 10y ago
What's hkt?
- thijsvandien 10y ago
  Higher-Kinded Types "With higher-kinded types [...] type operators can be parameterized by other type operators. Java doesn’t support higher-kinded types, but, if it did, you would be able to write something like this:" class GraphSearch<T> { T<Node> frontier; } Source: https://www.stephanboyer.com/post/115/higher-rank-and-higher-kinded-types https://www.stephanboyer.com/post/115/higher-rank-and-higher...
Rickasaurus 10y ago
We're working on Type Classes. It seems like HKTs (or anything like them) are going to be hard without diverging in a huge way from the rest of the .NET ecosystem.
- KirinDave 10y ago
  I really think Type Classes will address 90% of what people want without requiring deep hackery. The solutions we have with class dispatch right now are workable but awkward.
- jhomedall 10y ago
  That's fantastic news! I currently use Scala for most of my personal development, but having type classes would make F# attractive enough for me to switch over. I much prefer the cleaner syntax of F#. Losing HKT would be a shame, but that's a trade-off I would be willing to make.
  - willtim 10y ago
    Scala has never properly supported HKTs though. When I last tried it, there were multiple open issues, e.g. the partial application of type parameters. So I really don't buy the argument that Scala scores a point over F# due to HKTs. If you want HKTs, use Haskell.
    - daxfohl 10y ago
      It scores at least 0.7 points though. That said, it loses points elsewhere (as do all languages).
- daxfohl 10y ago
  I'm curious, will Type Classes enable http://www.sparxeng.com/blog/software/an-example-of-what-higher-kinded-types-could-make-possible-in-c http://www.sparxeng.com/blog/software/an-example-of-what-hig... without needing HKT?
tpetricek 10y ago
Not only we do not need HKT, we also do not need Profunctor Optics.
- purity_resigns 10y ago
  They're a great way to massively slow down both your build and runtime by an order of magnitude. I work with Purescript on a daily basis and don't see it as anything other than an anti-feature that allows for masturbatory FP.
- KirinDave 10y ago
  F# and its spirit animal OCaml are really great precisely because of this attitude. They're really good at saying "No" to things that offer at best incremental improvements at the cost of significant complexity. "Profunctor Optics" is a great example. Cool paper, but no thanks.
  - runT1ME 10y ago
    Higher kinded types reduce complexity in the same way generics reduce code complexity. If you think one makes things simpler but not the other, I would assume you're not familiar with it? Do you have examples of why it would add significant complexity? I use them constantly and it really simplifies my code a lot! Also, I don't believe 'profunctor optics' is a paper, I think it's just one (interesting) implementation of optics, which are useful in any language that encourages immutability.
    - KirinDave 10y ago
      The complexity that HKT brings to F# is not just conceptual. It needs to exist in the CLR which will bring implementation tradeoffs. "Cool paper but no thanks" is a saying for when people come to you with an extremely new technique and want you to incorporate it at the language level with very little proofing in the field. "Profunctor optics" is the a description of how profunctors encode lenses and similar structures. I am aware. I also think that technique can cook in Haskell land for a few more years before non-research projects should uptake it.
phillipcarter 10y ago
Awkward person who was in the video here The issue you're looking for (since an ask for HKTs typically means that Typeclasses are the ideal feature) is here: https://github.com/fsharp/fslang-suggestions/issues/243 https://github.com/fsharp/fslang-suggestions/issues/243 Please leave opinions, commentary, and vote if this is something you want! F# language design is done completely in the open, including motivation for features. Thanks!

alkonaut 10y ago

Wait what, doing this as an alias type ProductId = ProductId of int Meant it allocated an instance on the heap for it before 4.1? Wow.

edgyswingset 10y ago
That isn't actually an alias. That is constructing a single-case discriminated union. DUs are compiled into classes and have a few things automatic equality. Generally speaking, it's better to use Units of Measure[0] when you want some compile-time semantics around numeric literals, as these don't incur the performance penalty of creating a class. [0]: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/units-of-measure https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang...
- alkonaut 10y ago
  Yeah I realize there are more efficient aliases, but even so - just defaulting immutable data structures with only primitive types in them to cretae reference types feels like a massive foot gun performance wise. I couldn't imagine doing C# without value types, so for F# where things are usually more immutable, it has to be painful if e.g. a normal point(x,y) record is a class...
  - justneedvodka 10y ago
    You could use a struct, record, or tuple for a point. I've done all of these before.
    - alkonaut 10y ago
      Yes, and now they can be done right (as CLR structs)! It's just odd that this took until now. I suppose it just shows that those of us that are using .NET to do "C++ work" (always CPU and GC bound, almost never IO bound) are pretty few...

stcredzero 10y ago

I'm interested in .NET ecosystem languages, as well as functional programming. How is the parsing and meta-programming toolset? How easy or hard would it be for me to implement a subset of F# that only allows pure functions?

drbradley 10y ago
Very strong on the parsing front - FSharp.Data contains parsers and type providers for a variety of common formats and FParsec is a mature parser combinators library.
- VoiceOfWisdom 10y ago
  FParsec is fantastic. I have implemented a parser that supports a indentation based language in it. FParsec makes it very productive, and very fun.
  - mamcx 10y ago
    Is published? I have tried to use FParsec before for the same kind of language and failed.
    - VoiceOfWisdom 10y ago
      Its currently in a private bitbucket repo. I can give you the parser though, MIT licensed. ParserUtils is where maybeIndented and indented are. They make indentation just work. There currently overzealous with backtracking though, makes errors kinda shit. Working on that at somepoint. https://gist.github.com/xavierzwirtz/99479a11f1eefd3215467f7ea26b5c46 https://gist.github.com/xavierzwirtz/99479a11f1eefd3215467f7...
      - mamcx 10y ago
        Ok, thanks. But this not look more easy than just do it as TopDown Parser. But I don't know your language so it maybe have provided you with some benefits more than just lines of code?

tpetricek 10y ago

While it is great to see all those new features appearing in F# 4.1, the video gives a very narrow perspective on "what is new in F#" - it is a video about new language features in 4.1 and so this is to be expected - but if I was to list "what is new in F# in 2016", large portion of the list would include recent community contributions. Three recent projects are: * http://fable.io http://fable.io, which is a modern F# to JavaScript compiler that lets you build Elm-style apps, access React and all that fun * http://ionide.io http://ionide.io which is an F# integration for Atom and VS Code that is doing amazing work towards bringing F# to a fully cross-platform ecosystem * http://notebooks.azure.com http://notebooks.azure.com which is (very new) free Microsoft-hosted Jupyter Notebook service that provides support for the usual suspects (R and Python), but also ships with great F# support out-of-the-box In other words, I think the language is way ahead of the libraries and tooling - there is so much more that can be done (and is being done) using F# as-is!

partisan 10y ago
VS Code and Ionide work really well together. There are some slight issues like the loss of syntax highlighting in certain cases, but that is a really small issue. I am using this combination on a GalliumOS chromebook and it works out of the box in like 10 or 15 minutes: - install VSCode and then Ionide - install .net core - install mono (i believe ionide still uses mono) - install node and npm and then yeoman - install the aspnet generator for yo - "yo aspnet" will give the option to generate a working ASP.NET F# website
- mamcx 10y ago
  > VS Code and Ionide work really well together Not in my experience. Never since it appear the setup have worked for me, not even once. I try again last week. I need to copy-paste the .sh script from github because the one it generate was wrong. P.D: I don' use yeoman. NPM bloat is not my style: I follow the MS tutorial: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-vscode https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...
  - 10y ago

jackmott 10y ago

Some nice performance improvements in the core libs and compiler as well.

grayrest 10y ago

So, I've been making a slightly more concerted effort to pick up F# because I've always liked F# and .Net core and Fable means that I might actually get to run it at work without the non-starter of switching stuff over to windows servers. Excellent. The main holdup is that the build/packaging situation is disastrous. Most stuff still relies on Mono, which is fine, but trying to get things running on core quickly runs you into articles that assume you know exactly what you're doing and how all the pieces fit together, which is also fine. What's not fine is that the base task of wanting to download existing packages and run the result doesn't have a simple solution. The base .net core install comes with a project.json solution, which seems completely sane to me, but apparently that's deprecated and not how to do things. Then there's Nuget which is a package repo but apparently not a package manager because it's supposed to be a VS extension but maybe it is in the next version because there's a shell. There's also msbuild and some variant of it for fsharp which is mostly opaque XML but can be managed using a project called forge, which seemed to kind of work for me but also seems very opaque. There's also paket which manages dependencies from nuget, there's also Fake which seems to be a Rake-like build system. I know I'm not the only one who's run into this. I've seen at least 4 other requests for help in various F# forums and everybody seems to pretty much shrug and say that they use VS. If one of the F# cognoscenti could write up simple instructions on how to set up a project and run it using VSCode and .Net core, I'd be grateful.

phillipcarter 10y ago
Awkward person in the video here... Let me see if I can clarify the landscape a bit here: .NET Core tooling support is still in absolute Preview. The runtime and libraries are stable, but the .NET Core SDK, MSBuild support for .NET Core, the project system in Visual Studio, etc. are all Preview support. Much of the F# community is waiting on .NET Core tooling stability to act, which they have every right to do. .NET Core tooling is still in Preview, and still changing rapidly. Using any cross-platform community tooling or libraries on .NET Core is likely going to be rough right now, and that's because the underlying tooling that the community needs to rely on is in Preview. F# support is still officially in alpha for .NET Core, a moniker we're pretty deliberate about because we don't want to "flip the switch" until everything is stable and compatible with existing code. Honestly, if the churn is painful for you, the best advice I can give at this point is to wait until the tooling for .NET Core stabilizes and becomes release-quality. Up until that point, there will still be churn.