
What's New in F# 4.1? [video] - LyalinDotCom
https://channel9.msdn.com/Events/Connect/2016/118
======
tpetricek
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
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
> 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...](https://docs.microsoft.com/en-
us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-vscode)

~~~
phillipcarter
_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#.

~~~
mamcx
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...](https://github.com/ionide/ionide-vscode-
fake/blob/master/build.sh)

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

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

------
LyalinDotCom
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...](https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-into-f-4-1/)

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

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

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

------
stcredzero
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?

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

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

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

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

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

~~~
LyalinDotCom
good point! sorry for not adding it right away

------
alkonaut
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
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...](https://docs.microsoft.com/en-
us/dotnet/articles/fsharp/language-reference/units-of-measure)

~~~
alkonaut
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
You could use a struct, record, or tuple for a point. I've done all of these
before.

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

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

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

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

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

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

