
Is F# Ready for Production? - d2p
http://blog.dantup.com/2014/04/is-fsharp-ready-for-production/
======
skrebbel
> _5.Hiring developers is already very hard. Do we want to limit the pool of
> available candidates significantly (and take the increased salaries that
> come with the harder-to-find skills)?_

To that one, if I were in your shoes, I'd answer "yes" in a heartbeat. Using
F# can help you differentiate yourselves on the job market. Everybody's
looking for great developers, but you guys have a big plus when recruiting
developers who prefer functional programming.

As an anecdote, Dutch startup Silk writes their entire backend in Haskell.
Their founder Salar told me that while _finding_ people is harder, the people
they find are, nearly without exception, really good and passionate. They want
to work for Silk because they want to code Haskell for their day jobs. They
don't cost more than "other" developers at all, because they're so happy they
can finally use what they feel is a decent programming language at work.

I guess F# has a bit less of a hardcore following than Haskell, but I bet that
if you're one of the few functional programming shops in the region,
Haskellers (and MLers and maybe even Lispers) will definitely prefer that over
C# or Python.

~~~
d2p
Maybe so; though job ads I'd seen for F# seemed to have higher salaries.
Possibly that was just because of where they're based (London salaries are way
higher than here, for example)

~~~
profquail
The job ads for F# usually do have higher salaries than those for C#
programmers. However, I think you misunderstand why that is the case; it's not
(just) because good F# developers are harder to find than good C# developers,
it's because a good F# developer will be more productive, even more so than
reflected by the salary ratios. A good F# developer is (almost always) going
to also be very proficient in C# too, so they'll be able to switch back and
forth _easily_ and use whichever language is better-suited for a specific
project.

~~~
_random_
Please don't put F# on a shiny golden pedestal. A good C# developer can use it
without any problem as well. You of course would need to be open-minded enough
to understand that a C# developer doesn't mean an imperative developer. I am
not the best developer at all, but my C# code tends to be quite functional and
I prefer using the Maybe monad to deal with nulls in some cases for example. I
just don't see any massive obvious benefit of loosing the tooling and
ReSharper to switch to F#. Especially now that C# is open-source and the
Roslyn is nearly there.

PS: a good JavaScript developer will probably be even more productive than
both C# and F#, despite the language being horrible.

~~~
profquail
Well, by switching to F# you get much better type inference, discriminated
union types, pattern-matching, explicit tail-recursion, serializable types by
default, and type providers (and that's not even a comprehensive list). I
suppose it depends what type of app you're building as to whether those are
worth anything to you -- but in the areas where F# is rapidly getting more
popular (data science, numerical/algorithm-heavy work, distributed computing)
they do in fact make you much more productive. A good chunk of that
productivity gain results from being able to easily and quickly write type-
safe code and express algorithms without a great deal of syntactic overhead.

A JavaScript developer might be more productive than either a C# or F#
developer depending on what kind of app he/she was writing; overall I don't
think that would be the case, especially once you factor in maintenance costs
of the code over the long-term.

------
jackfoxy
I can confidently answer "yes" to this question, because Tachyus, the first
Silicon Valley start-up in the oil and gas industry,
[http://dealbook.nytimes.com/2014/04/10/tachyus-a-data-
start-...](http://dealbook.nytimes.com/2014/04/10/tachyus-a-data-start-up-for-
oil-industry-raises-6-million-from-founders-fund/) , chose F# as the core
software language. How did this work out? We went from absolutely no software
written to deployed as the core operational software of a regional oil
production company in 12 weeks. Our management and our customer's management
are so happy with the results we are "all in" and not looking back.

~~~
Serow225
What are your thoughts/experiences/workarounds about the points he raised in
the article?

~~~
jackfoxy
> _IDE support even in Visual Studio 2013 is absolutely poor_

It suits my needs well. References for functions/values/types would be a big
_nice to have_ , but I don't miss it that much. Refactoring? Rename
refactoring is in the F# community Power Tools
[http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-...](http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-4c0b-8bac-86d774189cff)
I've never missed it enough to bother. As for the show-stopping bug in the
Power Tools formatter, I would not want software someone else wrote re-
arranging the white space in my file. Beyond that _refactoring_ support is
rather ill-defined. Making a mish-mash of functional and imperative code more
functional/compositional/readable requires thought.

> _Options are great; nulls are bad_

Many functions in the .NET Framework now support a _try_ version which
interface very well with F#, thank you. Other than that F# cannot perform the
miracle of making external software null safe.

> _F# was completely missed from Roslyn_

I respect the OP, but I couldn't care less. (See my next comment.) Roslyn in
many ways is just playing catch up with F#, anyway.

> _There’s little info on what’s coming in the next version of F#_

As a language, F# is pretty feature mature. (The big thing I would like to see
is dependent types.) The action going forward is with the open source
community, [https://groups.google.com/forum/#!topic/fsharp-
opensource/1C...](https://groups.google.com/forum/#!topic/fsharp-
opensource/1CrjP7i0AN4), which Microsoft fully supports, as it should be with
a fully open source language. I know people in the community who already have
compiler enhancements, for instance, that should come around in the
foreseeable future.

> _Hiring developers is already very hard_

Fortunately for Tachyus, we have a compelling technology company story and a
growing team that makes the F# people (and not just F# people) we want to
recruit also want to join us, going so far as to relocate across the country.

This of course does not work for the IT Department of Acme Industries in
Flyover, Kansas. The HR department will hate you, but the best alternative is
probably to build a core of F#'ers internally. You will have to be creative
about your recruiting after that. You need to demonstrate your organization
offers a career rather than just a job.

~~~
Serow225
Thanks!

------
tpetricek
For those who expect that Betteridge's law of headlines ("Any headline which
ends in a question mark can be answered by the word no.") applies here, the
article is actually quite positive about F# :-)

But even then, it is just worth pointing out that there is a massive list of
testimonials from those who are already happily using F# in production in a
wide range of areas, including finance, science, line-of-business, startups
and many more:
[http://fsharp.org/testimonials/](http://fsharp.org/testimonials/)

~~~
d2p
Haha :)

The title could be qualified with "in our company", but then nobody would read
it! ;)

I love F#, but I'm not sure it's currently getting the love it deserves from
MS :(

~~~
tpetricek
To be honest, I think that "not getting the love it deserves from MS" is the
best thing that happened to F# :-). They did really good job at supporting the
community - by open-sourcing F# and now also accepting contributions to the
official MS release.

But the fact that they did not keep full control of F# means that the
community had time to setup "The F# Software Foundation"
([http://fsharp.org](http://fsharp.org)) and develop a really healthy open-
source ecosystem around F#.

If you look at the data-science story around F#, there are libraries like F#
Data, Deedle, R Type Provider, etc. I'm biased, because I contributed to most
of them, but I think that community did much better job than Microsoft would
in this area. So "not getting the love" is more like "getting freedom". And I
think it really helped F# in many ways.

Do not get me wrong - MS is an important contributor and everyone in the
community acknowledges that. But they are just a part of the F# story (there
is excellent Xamarin support, great open-source projects etc.)

~~~
d2p
For the language, maybe so; but MS are building great tools for C#/VB and it's
senseless for the community to reimplement them for the "other" .NET language
:(

The refactor/codefix support in Roslyn/VS is great; but I wouldn't even know
where to start doing something similar in F#? Can I reuse the functionality?
Or is the editor so disconnected that I'd need to implement all the menu etc.
myself too? (This would make it inconsistent and not play nice with
submissions else's CodeFixes that might draw menus).

------
tonyabell
many of the concerns the op had where with marketing of the f# ecosystem.

For example the tooling issues he mention are solved with a Visual Studio
Extension

[http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-...](http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-4c0b-8bac-86d774189cff)

His concern with Roslyn seems like a non issues, a f# compiler is also opened
sourced and was written in f# on day one. And there are many tools already
taking advantage of it being open. So in this regard f# is farther ahead in c#
in rubric.

As far a c# being ahead of f#, its funny, as most of the new features the are
being added to c# seem to come from f#.

The op approach to hiring dev seems backward to me, you hire smart people and
train then on your tools. There are so many good recourses for learning f#,
having candidates without f# on their resume does not seem like a issues.

over it is great the he was able to bring f# into his environment. as more
people adopt f# for there needs knowledge will spread and his concerns will
fade.

~~~
d2p
I did mention that extension; and the bug I found right away :(

Roslyn isn't just about being open source; there's functionality like the
Diagnostics/CodeFixes that make it trivial to do some really useful things,
which are significantly harder using the F# source.

Overall my conclusion is not that F# is bad; I really love it; but there are
some niggles for me still... Mostly around the level of investment from MS :/

------
endeavour
This article is ridiculous. F# is used in production in lots of places from
startups like Tachyus and SnappyGrid, to mid-sized firms like Trayport all the
way to huge corporations like Aviva, Credit Suisse, EDF and Barclays Capital.

IDE Support: Sure, the IDE support might not be quite as developed as C#. But
frankly most refactorings are just pressing tab a few times with F#.
Refactorings for C#/VB.NET are mostly workarounds for languages that require
huge amounts of excess syntax. The IDE support for F# is still way ahead of
most of the competition (particularly dynamic languages). The intellisense and
error highlighting work fantastically well.

Options/nulls: Yes I suppose you still occasionally have to do a null check if
you interface with legacy libraries. but I think having thousands upon
thousands of .NET libraries means this is a worthwhile tradeoff. Plus you can
use the TryGetX methods in F# far more nicely than in C#.
[http://luketopia.net/2014/02/05/fsharp-and-output-
parameters...](http://luketopia.net/2014/02/05/fsharp-and-output-parameters/)

F# missed by Roslyn: F# has had an open source compiler written in F# for
years. C# is a ridiculous language to choose to write a compiler in. See
[http://fsharpforfunandprofit.com/posts/roslyn-vs-fsharp-
comp...](http://fsharpforfunandprofit.com/posts/roslyn-vs-fsharp-compiler/)

What's coming next: F# is so far ahead of C#/VB.NET that this argument is
ludicrous. Even if F# remained stagnant it would still always be better than
C#. It has sensible defaults: immutability over mutability, functional over
OOP, parametric polymorphism over inheritance, lack of nulls over null checks
everywhere.

C# has poor defaults that are now irreparable due to the need to keep
backwards compatibility.

F# is open to contributions now so I would expect some great things. Joinads,
for example... [http://tryjoinads.org/](http://tryjoinads.org/)

Hiring developers is hard: This is a nonsense statement. Sure, if you want to
hire 100 F# developers you might struggle, but you're going to struggle to
find 100 good C# developers. Yaron Minsky from Jane Street reports hiring
OCaml developers was "the easiest hiring he's ever done". If you tweet that
you are looking for F# developers I know from experience that you'll get a lot
of responses from very talented developers. Most places I've worked have a
terrible time finding decent C# devs - interview:hiring ratio is around 50:1.

~~~
d2p
I didn't conclude it wasn't ready; it was an open question documenting my own
concerns. The IDE support is poor compared to C#, which is what we're
currently using. Roslyn isn't just about open source (nor writing a compiler
in C#!); there's a bunch of functionality (like refactor, diagnostics, code
fixes) that will breed a bunch of new tools that F# is sadly not on the boat
for :(

~~~
personZ
Your post is reasoned and fair, and some of the bizarrely defensive replies
you have received are just wholly undeserved. People vest too much of their
ego into technology choices, and it reflects in that sort of over the top
hostility.

~~~
endeavour
I wasn't being hostile at all, or at least that wasn't my intent. I explained
why I disagreed with each of the points made.

~~~
personZ
Calling a reasoned, even-handed assessment "ridiculous" sets a pretty bad tone
at the outset. That tone continues through your post (e.g. hiring difficulties
are "nonsense").

The submission asks a question that many shops confront when F# is proposed.
And the reality today is that many come to the conclusion that no, it isn't
ready for production, for many of the reasons the submission notes. Your
outrage will not change this reality.

------
overgard
Having used F# in a professional context (ok - I wasn't supposed to, but
technically I got paid to do it), my general impression is that it's slightly
better than C#, but not so much that it's really worth the effort to move
towards it. Ask me in 2005 and my response would be totally different, but
basically C# already co-opted most of the nice features F# brings to the
table, so the only real downside of C# is that it's slightly more verbose and
the type system isn't quite as good. In a vacuum I'd rather use F#, but all
things considered C# is (almost) as good and using it brings a lot less
friction.

Not to mention that it sort of brings a bit of weird legacy cruft from OCaml.
Granted C# also drags along some annoying legacy cruft from Java, but using F#
on the .NET stack always felt a little bit alien. It was nice, but it
definitely didn't quite "fit". How to write "standard" C# always felt pretty
simple, but I could never quite figure out what "standard" F# should look
like, and it generally clashed a bit with code from other languages.

~~~
seanmcdirmid
I once showed some of my C# code to Don Syme and he told me...that looks a lot
like F# :) The biggest challenge, I guess, of F#, is that C# isn't that broken
like say...Java is compared to Scala.

------
ufmace
I'm curious about your experience with Powershell now. Did you put much work
into using it to automate your processes? I spent about half a day or so
looking into Powershell at our all-C# shop, and decided to use Ruby for my
automation instead, which I have much more experience with. If you moved away
from it, what are you using instead?

The first task I tried to pick up was doing backups and restores of our SQL
server databases. I spent a couple of hours and couldn't figure out how to get
Powershell to do that, but it took about 10 minutes to find a T-SQL command to
do what I wanted, figure out how to run it from the command line using sqlcmd,
and set up a Ruby script to automate it and generate the commands dynamically,
etc.

Powershell also seems to require installing dozens of little thingys for using
most of its features, all of which are very picky about bittedness, and which
are mostly tucked away in weird corners of Microsoft's sites. Ruby has one
installer on an easy to find site, though I admit it took a while to discover
that using anything but 32-bit 1.9.3 on Windows will only lead to pain.

~~~
d2p
We automated quite a bit with PowerShell. Our deployment scripts which unzip
releases, update IIS config (apppools, virdirs, new sites) and our scheduled
jobs are all done via PoSh. We also use it for lots of generation/execution of
ad-hoc SQL for data manipulations.

As a shell (especially remoting to servers); it's great. As a scripting
language, ironically I'm more likely to use F# (FSI) these days, mainly due to
two serious bugs in PoSh Scheduled jobs we've never gotten any response from
Microsoft over :(

------
platz
I'm much more optimistic on F# after watching this video series from Mark
Seemann on pluralsight. He addresses some of the tooling issues and shows how
to build a nice API in F#.

[http://pluralsight.com/training/courses/TableOfContents?cour...](http://pluralsight.com/training/courses/TableOfContents?courseName=functional-
architecture-fsharp)

------
pnathan
What I see in closed source systems - this is particularly clear in MS - is
that the developers are always waiting for the controlling company to do
something.

I don't see this same attitude in open source - the users are common major
contributors to the ecosystem.

Just something I've noticed.

~~~
tpetricek
I completely agree with your observation, but I'm not sure what is the point
that you're trying to make here :-). F# is open-source and has a very active
community that is contributing to many core parts - including the tooling
([http://fsprojects.github.io/VisualFSharpPowerTools/](http://fsprojects.github.io/VisualFSharpPowerTools/)
and [http://fsharp.github.io/FAKE/](http://fsharp.github.io/FAKE/)), the
compiler now also accepts contributions and there are a few work-in-progress
pull requests, as well as building some of the core F# libraries, e.g. for
data science
([http://fsharp.github.io/FSharp.Data/](http://fsharp.github.io/FSharp.Data/),
[http://bluemountaincapital.github.io/Deedle/](http://bluemountaincapital.github.io/Deedle/),
etc.)

I think the F# community is much more like the "open source" model than the
"closed MS model". The change is slowly happening in the rest of .NET, but F#
is way ahead here.

