
A Peek into F# 4.1 - douche
https://blogs.msdn.microsoft.com/dotnet/2016/07/25/a-peek-into-f-4-1/
======
KirinDave
I wish I could convince more people of the importance of F#. It sits in such a
unique place.

Its Ocaml heritage gives it tons of advantages over other functional languages
rolled from scratch when it's time to write server or application code, it has
a class library equivalent to the Java stdlib behind it, and its focus on data
processing has made it a good choice for people doing data science.

~~~
catnaroek
If it only had an actual module system - that is, an ML-style one...

~~~
KirinDave
That is by far it's worst feature. I totally agree.

------
saosebastiao
I'm not a fan of the new syntax for struct tuples, struct records, and struct
unions. I feel like it could have been avoided with a lesser evil if they had
followed the same approach that Scala is using for anonymous functions in the
upgrade to 2.12.

Specifically, _don 't introduce new syntax_, but force your users to deal with
the fact that your bytecode is now incompatible with previous versions and now
requires a new minimum version for the VM. They can recompile...it's not
really that big of a deal. It is far more of a big deal to rewrite all of your
code than it is to upgrade your VM and recompile.

~~~
akra
I definitely agree with you for tuples especially smaller tuples. As tuples
get larger however performance can swing the other way. As someone who codes
some F# for my day job it seems that while tuples should be easier in a
functional language like F# for backwards compatibility struct tuples will be
more awkward to use than in C# 7. I think they should of just bit the bullet
for tuples up to a certain size.

For records and unions however I think the attribute is fine. Most of the time
for types of more than 3 fields say structs can be worse in performance than
classes anyway. Records and unions tend to be assigned more and live longer
than tuples most of the time. For unions for obvious reasons structs are not
recursive in nature which with unions is required somewhat (see
[https://msdn.microsoft.com/en-
us/library/ms229017%28v=vs.110...](https://msdn.microsoft.com/en-
us/library/ms229017%28v=vs.110%29.aspx)). Definitely wouldn't want structs to
be the default here.

~~~
MichaelGG
This tuple stuff is a mess. From the RFC: >This is based partly on the
assumption that the proposed C# 7.0 tuples will use struct representations for
at least some small tuple types.

This is what F# had to begin with! They were sort of pushed into using a heap-
allocated type via System.Tuple, in the name of compatibility with the rest of
.NET. Frustrating!

It's also sad to see no mention of really improved tooling, to put F# on the
level of C#. MSCorp paid some lip service, well overdue since the F# guys are
the ones that gave them generics which was the biggest thing technical
advancement .NET had over Java.

~~~
phillipcarter
> It's also sad to see no mention of really improved tooling, to put F# on the
> level of C#.

Could you clarify what you mean here? Perhaps I could have written more about
it in the blog post, but sitting the language service atop the Roslyn
Workspace layer is critical work that:

1\. Gives F# a "modern" editor experience out of the box.

2\. Gives F# an entry point into the large amount of Roslyn-based IDE
features. Workspaces are how they "talk" to the language, so that means that
they can now "talk" to F# as well. This is not possible with tooling today.

This also has another big impact: F# will be able to use the CPS-based project
system that is being built for C# and VB right now:
[https://github.com/dotnet/roslyn-project-
system](https://github.com/dotnet/roslyn-project-system)

~~~
MichaelGG
Hmm, how much does this provide? Will this make, say, F# interactive
competitive with C# interactive? (Which blew past it, despite F#'s near-decade
lead.)

I'm tentatively hopeful I suppose.

------
codelike
F# is definitely a great language. It would be amazing if the interop with
Entity Framework was improved, too, with regards to code-first development.
Not having a nice and easy way to define virtual properties on records and
classes is something I miss a lot:

[http://stackoverflow.com/questions/26775760/how-to-
create-a-...](http://stackoverflow.com/questions/26775760/how-to-create-a-
virtual-record-field-for-entity-framework-lazy-loading)

Not sure how difficult it would be to implement a [CliVirtual] attribute
([https://fslang.uservoice.com/forums/245727-f-language/sugges...](https://fslang.uservoice.com/forums/245727-f-language/suggestions/6672675-an-
clivirtual-attribute)), but that would definitely help and make the EF-models
more readable.

But in general, F# is great. I hope more people will use it.

------
partycoder
I am very glad that Microsoft continues to actively support F# and I hope to
see it making its way into more projects in the future.

------
ElliotH
It's pretty cool being able to get this setup on my Mac and easily play around
from the command line. It makes it much more accessible as a language than
when it was more closely tied to the Windows/Visual Studio ecosystem.

~~~
douche
I've probably spent more time messing with F# on my Mint laptop than I have on
my Windows desktop...

Part of that is that F# doesn't really have the level of tooling that I've
come to expect from C# in VS, with ReSharper.

I would like a static analysis tool for F# that tells you when you are doing
something that is legal, but dumb, as ReSharper does.

~~~
smoothdeveloper
Consider using
[https://github.com/fsprojects/FSharpLint](https://github.com/fsprojects/FSharpLint)

I'm not sure if it is integrated to ionide yet.

~~~
cloudroutine
it is for atom, not yet for vscode

