
Getting started with the F# and .Net ecosystem - DanielBMarkham
http://www.prigrammer.com/?p=363
======
qaid
I was introduced to F# 3 years ago at work, and have been developing with it
for more than 2 of those years (in production, some apps mixed with C#, others
pure F#)

My quick thoughts: Beautiful language. There's quite a bit of a learning curve
for some of the more advanced features, but a large portion of the language is
very readable and succinct Additionally, I love how the language has helped me
become a better developer. Far fewer bug, and none of them are null-related
After my former lead left, I've had difficulty introducing new teammates to
the language. It's hard to convince C# devs to try it out I've been looking
around for a long time, but there seem to be very few teams that are hiring
F#. It doesn't help that many aggregate job posting sites fail to show useful
results when searching for "F#" Negatives aside, I really enjoy programming in
F# and if you were on the fence, I'd say to give it a try!

------
vicpara
I'd love to use F# in production on a Linux/Mac OS environment. I find the
tooling to be problematic and quite hacky on these platforms. In the same time
the library ecosystem around manipulating PDF/Word/XLSX documents, CPU/GPU
math accelerated libraries, machine learning, stats, charts and DB connectors
are not that mature and production ready. If you just stay withing the F# and
.NET core library ecosystem then it's fine. I'd need more support for the
ecosystem to be able to fully switch from scala to F# for production. I'm so
looking forward to having Microsoft get the full .NET to Linux.

~~~
nobleach
I have been feeling this way for quite awhile. I never want to detract from
anyone's hard work, but I simply hate Mono. I hate having to fool around with
it to get something else to work. When MS released C# for .net-core, I was
extremely pleased. I'm not a big MS fan, but C# is really good! Being able to
run it on Linux is a great step forward. I know MS has a roadmap to get F#
going, so I'll be anxiously waiting.

------
cm2187
There was a nice video on F# 101 on MSDN recently:

[https://channel9.msdn.com/Shows/On-NET/A-tour-of-F-with-
Phil...](https://channel9.msdn.com/Shows/On-NET/A-tour-of-F-with-Phillip-
Carter)

There are two passages that I found amusing.

First the guest mentions the merits of F#'s deep implicit typing, where the
use of a function at the top may determine the typing of other nested
functions. And as one would expect with this level of things happening
implicitly, it is very easy to get lost in what is going on, which is exactly
what happened to the guest at minute 27, where he couldn't figure out why the
F# compiler wasn't implying the correct type.

Later on the guest mentioned that for all their API, they actually create a
signature file (i.e. a header file) where you have to declare every function
signature separately from the implementation. The host diplomatically mentions
that perhaps this might maybe be a little bit cumbersome to maintain. The
answer is that it's not a problem, as the program simply doesn't compile if
you have a mismatch.... Hum.

I like certain aspects of it, not using too many special characters (kind of
python/vb style), the immutability, etc. But I can't say I am sold and ready
to switch though. And many of what are presented as key features are just not
the kind of things I have any use for, like declaring lists of consecutive
numbers (can't remember the last time I needed one) or F# type providers (I
rarely have to deal with unexpected file data formats).

~~~
yawaramin
Yes, to be honest in languages with type inference you have to rely on your
editor/IDE to show you types on demand. You do need that to be able to work
smoothly on a day-to-day basis. Of course you can and should learn how to
reason about the types, but you still need quick feedback about whether the
compiler agrees with your reasoning.

To your second point, about the 'header' (interface) files in ML-family
languages like F#--that is a really great feature because it lets you do
_abstraction_ and _access control._ The interface file specifies what callers
are allowed to see, you can use them to make your types truly abstract and
prevent access to your modules' internal functions.

About lists of consecutive numbers ... not sure what that is referring to
exactly. About type providers ... yes, I agree with you that not everyone
finds a use for them. In general, I will say that the killer feature of F# and
other ML-family languages is that they dramatically increase code
refactorability (low-ceremony static types) and dramatically reduce lines of
code (simple, 'math-y' syntax).

~~~
cm2187
For consecutive numbers I am talking about the [1..99] notation. Very useful
in academics to make a demo when you don't have real data. But less so in the
real world. What I mean is that many of these demos tend to address problems
that I do not have personally.

Multithreading is a good example. It is hard to do at a low level. And I
totally get why F#'s approach helps a lot. But I find that you get most of the
benefits of multithreading by splitting your task in independant subtasks that
are not thread safe but do not share writable data, and run a parallel.for at
the top. Occasionally you need some locking if you have a common cache but
that's easy to get right.

Sure you could optimize it a little bit more by making it multithreaded at a
lower level but most of the time that's enough to get 90% of the performance
benefit.

I am also a bit uncomfortable with the liberty F# takes with memory. To make
everything immutable you create a lot of copies in memory. All the .net
performance articles I have read mostly focus on taking it easy with the
garbage collector and reducing the number of allocations. Intuitively it
doesn't sound like an obvious trade off (thread safety vs more garbage to
collect).

~~~
yawaramin
Oh, the range notation. It's a little convenience that can save a bit of
typing here and there. Not a tremendously important feature, to be honest.

About multithreading, not sure what you mean but F# definitely has parallel
collections in addition to its general async capability that lets you handle
concurrency in a safe way. If you haven't already, check out the Hopac project
([http://hopac.github.io/Hopac/Hopac.html](http://hopac.github.io/Hopac/Hopac.html)
, scroll down to the Description section).

About memory use, yes you create copies but at the same time immutability
means you can have persistent data structures which share and thus save a lot
of memory. Also, in general performance is good enough that you don't really
have to worry about it, and when you do, you can always measure, profile, and
see what's actually causing the memory pressure.

That said, it's true that functional programming languages have a different
memory profile than imperative languages, and implementations which have been
designed with this profile in mind perform really well. E.g. check out OCaml's
performance in this GC pause benchmark: [https://making.pusher.com/golangs-
real-time-gc-in-theory-and...](https://making.pusher.com/golangs-real-time-gc-
in-theory-and-practice/)

------
dev360
I know its heresy, but for a while I was actually getting hooked on F#
succinct way to write/support OO. On the surface at least, it looked a lot
cleaner and more concise than C#.

I wish there were more F# jobs - its a very interesting language.

~~~
ydt
Not heresy at all. Everyone I know that has used it, including myself, really
likes it. Yet no one I know has ever used it a real production environment. I
guess it has some traction in financial circles, but that's about it. Maybe
.NET going cross-platform will lead to some adoption.

~~~
jackfoxy
We at Tachyus use it as the main server-side language in our production
environment. Also on Linux/Mono. Jet uses it, and they were bought by WalMart
for > $1B. There is no problem running in production. In fact, there is a
noticeable lack of problems running in production.

------
smortaz
in case you'd like to get a quick intro to the language w/o installing
anything, check out their jupyter notebook here which you can clone & run:

[https://notebooks.azure.com/Microsoft/libraries/fsharp](https://notebooks.azure.com/Microsoft/libraries/fsharp)

------
equalunique
Thanks a lot for posting this.

I have been wanting to break into F#. At work I use PowerShell on many Windows
computers. I could write PowerShell modules in C#, but F# would allow me to
think like I would if they had been written in Haskell.

I am also working on a small web application with C#. (M101N course via
MongoDB Uni.) I'm keen on re-implementing in F#, just to see how both compare.

Appreciate the getting started guide!

~~~
pjmlp
That is my current approach, as I don't get to use anything other than C# (or
C++) on .NET/UWP projects, so F# gets used for my own scripts.

------
cjnicholls
If you have issues accessing it.

[https://web.archive.org/web/20170607134504/http://www.prigra...](https://web.archive.org/web/20170607134504/http://www.prigrammer.com/?p=363)

------
polskibus
Does F# have Generalized Algebraic Data Types like Ocaml has?

~~~
Nelkins
No, but you can get very close using classes/objects. See
[https://eiriktsarpalis.wordpress.com/2017/03/20/why-oo-
matte...](https://eiriktsarpalis.wordpress.com/2017/03/20/why-oo-matters-
in-f/) and [https://www.microsoft.com/en-
us/research/publication/general...](https://www.microsoft.com/en-
us/research/publication/generalized-algebraic-data-types-and-object-oriented-
programming/) for more details.

------
mikerg87
This talks about mono and I certainly think it's a nice option. If you want to
use .netcore and F# (even on mac and Linux ) here is a nice getting started
vid :

[https://channel9.msdn.com/Events/Build/2016/T661](https://channel9.msdn.com/Events/Build/2016/T661)

------
lobut
Any one that uses F# right now, can you tell me if you can create folders in
Visual Studio? It seems like it's mentioned here, but I'd like a confirmation.

~~~
akra
You can via the F# Power Tools; at least in VS2015. In VSCode just create the
folder as per normal and hit "F1->F#: Add File to Project" using the Ionide
plugin. Admittedly the need for folders in my experience is a lot less than in
C#.

