What's New in F# 4.1? [video] | Hacker News Reader

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

channel9.msdn.com

131 pointsLyalinDotCom62 comments

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, which is a modern F# to JavaScript compiler that lets you build Elm-style apps, access React and all that fun

* 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 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!

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

> 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/tuto...

The tutorial you linked is for developing against mono using Paket and FAKE. I also found it difficult to work with F# and mono. My recent and positive experience was with developing against .net core.

Also, you don't need to use yeoman, "dotnet new --lang F#" produces a blank F# .net core project and then you can add all of the dependencies manually.

Awkward person in the video AND author of that tutorial here...

I'd love to learn more about what went wrong in setup. Keeping that article up to date and, more importantly, correct is a priority of mine, because I really want people to learn about Ionide and F#.

I just follow the tutorial on OSX. Then I try to do the first build and get:

> build.sh: line 34: syntax error: unexpected end of file

So I delete the last empty line, and get:

> build.sh: line 33: syntax error near unexpected token `fi'

I don't see any wrong with the script (I don't know bash scripting). So I go to the github site and just copy from https://github.com/ionide/ionide-vscode-fake/blob/master/bui...

And it work.

This is the diff:

    diff -r 8b6c97c12f6e build.sh
    --- a/build.sh  Fri Dec 09 20:27:05 2016 -0500
    +++ b/build.sh  Fri Dec 09 20:27:50 2016 -0500
    @@ -3,7 +3,7 @@
     then
       # use .Net

    -  .paket/paket.bootstrapper.exe
    +  .paket/paket.bootstrapper.exe  prerelease
       exit_code=$?
       if [ $exit_code -ne 0 ]; then
        exit $exit_code
    @@ -15,7 +15,7 @@
        exit $exit_code
       fi

    -  packages/FAKE/tools/FAKE.exe $@ --fsiargs build.fsx
    +  packages/FAKE/tools/FAKE.exe $@ --nocache --fsiargs build.fsx
     else
       # use mono
       mono .paket/paket.bootstrapper.exe
    @@ -29,5 +29,5 @@
       if [ $exit_code -ne 0 ]; then
        exit $exit_code
       fi
    -  mono packages/FAKE/tools/FAKE.exe $@ --fsiargs -d:MONO build.fsx
    +  mono packages/FAKE/tools/FAKE.exe $@ --nocache --fsiargs -d:MONO build.fsx
     fi
    \ No newline at end of file

It's probably line ending problem. Running something like dos2unix on `build.sh` would probably fix it.

> 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!

I completely agree!

I wish I had more upvotes to give, since I'd give your comment the most if it were possible. I agree that there are some omissions from the community here, especially Ionide (which I personally use in addition to Visual Studio). I should probably do a video showing a breadth of F# tooling and libraries for F#, because it really is a great landscape where you can pick the tools and libraries based on their merit, rather than being stuck with one particular set of tools.

I was watching a Dot Net Rocks video[1] from 2012 with Don Syme being interviewed about the release of F# 3.0 and they ask him what's planned for F# 4.

He says that what devs are telling them is that the language is good, but they want better tools, so he wouldn't be opposed to a solid maintenance release just around improving tooling (but nothing is planned yet).

So the day after watching that, four years after the video, it's a bit weird to find you saying "F# 4 and now F# 4.1 - the language is way ahead of the tooling".

https://www.youtube.com/watch?v=mvYyI4kG1Vo

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

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.

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.

I don't have anything pressing and I don't know the ecosystem so I'll be waiting it out. My frustration is mainly that I think F# with Fable and Kestrel in VSCode is very compelling for JS shops and the only reason I can't recommend it is the build situation. An explanation of how to make a project, add a dependency, and run it that would make sense to someone used to npm would really help people who aren't on windows and running visual studio. I do appreciate the efforts of the F# team has always made in maintaining an open source community and I do recognize that there are lots of complications involved. Thanks for your efforts.

> I do appreciate the efforts of the F# team has always made in maintaining an open source community

I do appreciate the efforts of the F# open source community has always made in maintaining an VF# team.

i recently started dabbling in f#, and i've made a small collection of shell scripts that walk through the stages of setting up and compiling different kinds of program. the basic idea is that forge and paket do most of what you want; they're just hard to figure out; reading through the shell script will take you step by step through the various incantations you need.

thus far i have command-line "hello world", eto.forms gui and gtk# gui (they mostly differ in what libraries they install). if you're playing with fable, i'd love if you contributed a script.

https://github.com/martindemello/fsharp-quickstart

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?

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.

FParsec is fantastic. I have implemented a parser that supports a indentation based language in it. FParsec makes it very productive, and very fun.

Is published? I have tried to use FParsec before for the same kind of language and failed.

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/99479a11f1eefd3215467f7...

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?

Big benefit to me was being able to do it all with parser combinators, and without having to drop into another language like lex and yacc.

Parser combinators are top down parsers.

Very poor. You would pretty much have to build a language from scratch. I am working on doing that with a language called emly, supports effect tracking as opposed to haskell style purity. I am having to basicly do everything from scratch.

Like purescript?

If you wanted to create a version of F# that only allows pure functions, your best option is probably to modify the F# compiler (which is open source). However, that sounds like something that might not be all that useful.

A more useful thing could potentially be to use the "F# Compiler Service" (which is the compiler API, exposed via a nice F# library) and create some tool that checks purity. I think many people might actually be interested in something like this.

My purpose would be to create a multiplayer game programming platform. Basically, it would come with a game loop already running, with communications already working. Then you could modify the game by changing functions that transform game tick N to game tick N+1.

There's another way to do this. Just scan the compiled code for access to anything other than a fairly short whitelist of functions. This is how Terrarium worked.

Yup, this is the better approach to sandboxing. You can always expand a whitelist, but it’s not so easy to play black-a-mole.

Easy?

If we are talking about building a language in F#, remember that is possible to use any language for that.

In fact is make support for side-efects and mutating that complicate the build of a compiler/interpreter.

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

good point! sorry for not adding it right away

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

Do we really need them?

No. There's a difference between needs and wants.

Well if you don't think a modern FP language needs higher kinded types you probably do need vodka.

What's hkt?

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

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.

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.

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.

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.

It scores at least 0.7 points though. That said, it loses points elsewhere (as do all languages).

I'm curious, will Type Classes enable http://www.sparxeng.com/blog/software/an-example-of-what-hig... without needing HKT?

Not only we do not need HKT, we also do not need Profunctor Optics.

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.

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.

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.

Thanks for replying, yeah I suppose I didn't think about the ramifications of having to deal with reified generics and higher kinded types. I still think they're an amazing productivity boost, and the initial 'weirdness' of learning that particular abstraction pays off a tremendous amount in code readability.

As for the 'cool paper' comment, I wasn't aware of this new jargon, thanks for informing heh. I'm not sure how well it will play outside of haskell, I've done a Scala encoding of them and it's a bit more awkward than other representations.

Many people use the exact same argument to dismiss the entire functional programming field.

I'm sorry, but implicit slippery slope arguments are not a means by which one can force every functional language to run the project the way Haskell does.

But it's also worth noting that this is not a rejection of the entire concept of lenses, just that right now Haskell's implementations leave a lot to be desired (e.g., abandon all error sanity, ye who enter here).

Haskell is as much a research platform as a programming language, and as such it has the leisure to experiment this way. Everyone else will wait awhile for things to bake. Look what happened when Haskell built its entire stdlib on monad transformers and then we all realized they're awful compared to the alternatives.

I mostly agree with this. But nobody is "forcing" anything, one can still use Haskell and avoid the e.g. infamous (and non-idiomatic) lens library. But just as you haven't given up on lenses, I also don't agree with the wholesale rejection of ideas based on imperfect implementations, which is what prompted my comment.

Hey tomas!

This is why I love working on an open project like F#. We get to disagree in public! I would actually like Typeclasses, though I have serious reservations in terms of not breaking back compatibility. I'm certainly not about to get on a table and rant about how "it was truly the lack of better ad-hoc polymorphism via higher-kinded types that kept me from writing good software in F#!", and I see a danger in bifurcating the language .... but I like Typeclasses and think they do solve some more nuanced issues out there.

I should probably be putting my opinions on the Typeclasses thread...

Obligatory scene from The Jerk. https://www.youtube.com/watch?v=rSWBuZws30g&feature=youtu.be...

I would love to know how you live without HKT. Modules, perhaps?

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

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!

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.

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/lang...

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

You could use a struct, record, or tuple for a point. I've done all of these before.

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

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

Reply on news.ycombinator.com