
Ask HN: Why isn't F# more popular? - narimiran
I&#x27;m coming from Python world and I just started learning F# for fun (and profit ;)). So far, my experience with the language was quite positive, so I was bit surprised to see that F# is not more popular. I guess I wasn&#x27;t able to see its downsides just yet.<p>My question for more experienced F# programmers: What are the F#&#x27;s downsides which prevent its more widespread usage?<p>For other people who have tried F# and didn&#x27;t continue to use it: Why did you stop? Do you use other functional languages instead?<p>General questions: Is it because of its ties to Microsoft and&#x2F;or Windows? Is F# not as good as other functional languages (which ones are better, and why?)? Not enough learning resources, examples, etc.?
======
pritambarhate
Most of the programmers do programming for a living. They are not passionate
programmers who like to learn new languages. They care about getting things
done. Since Java, C#, Python, JavaScript, Ruby and Rails, PHP are all popular
and have huge library ecosystem around them, for most of the 9 to 5
programmers, there is little incentive learn any functional language.

Also since all popular and dominant languages are either Object Oriented
and/or Imperative, functional programming concepts seem too alien.

Even though I consider myself a fairly passionate programmer, I haven't found
enough incentive to invest proper time to learn a purely functional language.
The infatuation with Clojure and Haskell only lasted for a weekend for me. I
always think, that next month I am going to invest in learning a functional
language, but always something else more shiny comes along from other domain
like, Dynamo DB, Firebase, RabbitMQ, etc. Which I find more practical to learn
rather than learning yet another programming language.

~~~
maxxxxx
Agreed. I have tried using F# in my company but gave up after a while.
Reasons:

\- it's hard to hire people

\- most libraries are written for OO style so most code will be written OO
style

\- most sample code is written in C#

\- C# is a pretty nice language. Does F# really provide an advantage?

\- will MS abandon F#?

I really would like to see a clear case for F#. When you consider factors like
hiring and existing ecosystem the case for F# is not clear to me.

~~~
usgroup
Data wrangling is a really clear case. I do a tonne of this and it's so much
easier in FP.

~~~
vram22
Why is data wrangling easier in FP? Is it because of functional composition
being like using Unix pipelines (inside the same program)? But one can do that
in a procedural language that has functions too.

~~~
lobrien
Yes, functional composition in part. And while pretty-much-everyone has first-
class functions now, they're usually not _quite_ as easy to declare and use as
they are in F# (e.g., if you have to specify `Func<string, Func<string, int>>
Foo` rather than `let Foo s1 s2 = ... `

Another data-wrangling thing easier in F# (not FP in general) is type-
providers.

~~~
vram22
Thanks.

------
daxfohl
In corporate, especially in MS shops, to modify an old adage, "Nobody ever got
fired for choosing C#". For side projects, I'd imagine most people working on
those would rather do something not Microsoft-specific.

For me, I've done plenty of freelance projects in F# over the past few years
and enjoy it. I've done about two years worth of projects in Clojure, and
about a half year in Scala, and F# was the nicest of the three for me.

It takes a while to figure out your style however. Since it's a FP-OO hybrid,
there are often many approaches to doing the same thing
([https://fsharpforfunandprofit.com/posts/13-ways-of-
looking-a...](https://fsharpforfunandprofit.com/posts/13-ways-of-looking-at-a-
turtle/)) and lots of different "styles" of _how_ FP you want to go. Some
people end up with "C# in F#" and some go almost to "Haskell in F#". (I
personally end up somewhere in the middle). And until you figure that out,
it's hard to be as productive as in a language you already know. But once you
do, I think F# provides the ability to be more productive than C#. (Granted I
think immutable records and `with` syntax would get C# half way there).

However I will admit that when it comes time to transition the code back to
the owner, I kind of regret using an edgy language. Fact is most workaday
developers don't have a ton of interest in new languages and would rather work
with something they already know.

Most of the pain points are due to running on a runtime designed for OOP. So
even though idiomatic F# code shouldn't need null checks or much exception
handling, you still need them if you're using C# libraries. There's also an
annoying mix of camelCase and PascalCase everywhere (the former for logical
consistency: a function is a value, and the latter for consistency with C#
conventions).

~~~
narimiran
> I've done plenty of freelance projects in F# over the past few years and
> enjoy it

Could you give some examples of what did you do in F#? Did you choose F# just
because you wanted to see if you can do it in it, or did F# have some
advantages over other (functional) languages?

> It takes a while to figure out your style however. (...) Some people end up
> with "C# in F#" (...) And until you figure that out, it's hard to be as
> productive as in a language you already know.

My plan is to avoid as much as possible "writing Python in F#", because I
choose F# as an opportunity to learn something new/different (which might
transfer to writing better Python later). Any tips for this?

~~~
daxfohl
My main project over the last few years has been a photobooth, so I've done
server-side in suave (I LOVE suave compared to any other .net framework),
client-side in WPF (F# experience in WPF is meh), and a bundle of other mini
projects. I did it in F# because it was interesting, not because it was more
productive at the time.

My personal landing point is about #6 in the turtles article. I still like
classes and interfaces and think they fit perfectly well. However, inheritance
is something I avoid completely now. The effect can be done much more flexibly
and transparently by several other means. But one great thing about classes is
that you get nice autocomplete when you type `myservice.`. And note I only use
OO for "services"; data is data is data. So if you're doing DB stuff, prefer
an anemic data model and a platform that supports it (so Dapper rather than EF
or NHibernate). Basically do `db.Save(myData)` rather than `myData.Save()`.

Another big change I've noticed is I don't use "private" functions much
anymore. In OO I spent a lot more energy making sure that people using my
classes couldn't use them wrongly. They could only do exactly what the
requirements allowed. I think OO mindset (at least in C#/Java, maybe Python is
different) makes you paranoid and guides you to putting "app code" into what
should be "libraries". This sometimes made e.g. unit testing more of a pain;
you can't test your "validate" functions directly because they're private. Now
I tend to open most everything up and let developers do what they want with my
code, but I add a few helper functions to cover the common cases to guide them
in the right direction. In general I consider everything a library now; the
only "app-specific" code I write goes in `main` function that glues everything
together. Of course I still don't open functions that expose contained
services, or that leave things in an inconsistent state, but that's about all.

And of course embrace immutability and recursion (or the library functions
that do it for you).

Probably the most annoying thing for you, especially coming from Python, will
be "similar records". So you'd need a `User` that just has raw data, `UserDb`
that maybe has that plus an ID/DateAdded/DateModified, a `UserOut` that maybe
has that minus PasswordHash, a `UserIn` that maybe has
RawPassword/RawPasswordAgain, etc, and conversions between them all. Not to
mention if you want different schemes for jsonNaming, db_naming, RecordNaming,
etc. I've yet to come up with a happy typesafe way of doing this.

~~~
vram22
> So you'd need a `User` that just has raw data, `UserDb` that maybe has that
> plus an ID/DateAdded/DateModified, a `UserOut` that maybe has that minus
> PasswordHash, a `UserIn` that maybe has RawPassword/RawPasswordAgain, etc,
> and conversions between them all.

Why is this needed in F#? Something to do with immutability?

~~~
daxfohl
This assumes you want to use records for your data: records don't have
inheritance. So whereas in C# you could create a UserDb that extends User with
the Id/DateAdded fields, in F# that's not idiomatic.

I am sure there could be a good way to automate this using type providers, but
I haven't tried it yet.

------
ericssmith
As a long-time advocate of functional programming, I was once asked after a
talk what is the "best" FP language to learn. Since I'm known as a
Haskell/Scala/ML person, I surprised much of the audience by answering that I
thought F# was the best entry point. What I did not say, however, was that I
think that Windows is a challenging environment for anyone who is used to
Linux/Mac -- and this includes the "open source" world in general. I think
that Microsoft is a leader in language design, but their platform relevance
was slipping for many years. I believe it may be on the upswing (with Xamarin
etc). I would encourage you to stick with F# as you will be further along in
not only understanding FP, but other modern programming languages, including
ones that haven't been invented yet.

~~~
hota_mazi
Interesting.

To me, Windows has eclipsed both MacOS and Linux as the best dev environment.
It's caught up in shell and the whole ecosystem of tools completely blows away
what exists on MacOS and Linux.

Windows is also a lot better than the other two in keyboard shortcut support.

~~~
gjjrfcbugxbhf
Interesting. To me windows is a country mile behind linux as a dev
environment.

I don't really understand what you mean about keyboard shortcuts though. I
thought the windows ones are hard coded into the OS and can't be changed?

~~~
hota_mazi
Everything in Windows has keyboard shortcuts, not so on Linux and MacOS (e.g.
you can't open a random menu item with the keyboard).

~~~
gjjrfcbugxbhf
Um yes you can? I mean i do this all the time like many times a day all the
time... Alt key is your friend here

~~~
hota_mazi
Not on MacOS.

~~~
gjjrfcbugxbhf
MacOS is as unusable as Windows to me.

I think it depends on what you are used to though.

------
dgudkov
Because Microsoft could've promoted it more but it didn't.

>What are the F#'s downsides which prevent its more widespread usage?

The two biggest downsides I've encountered are not related to the language
itself. One is lagging support in Visual Studio (didn't support folders for
long time, poor cross-language C#/F# navigation, no support in .NET Core
projects etc.) and the other is the lack of examples/frameworks for WPF
applications when I needed them.

Other than that it's my favorite language for all kinds of tasks -- from
production apps to scripts.

~~~
narimiran
> One is lagging support in Visual Studio

I use VS Code, both for Python and now for F#, and so far my experience has
been positive. But that might be because I've used F# only for very basic
stuff, and I don't know how better it could be in some other language and/or
IDE.

> scripts

I think I'll stick with Python for that :) But I'm thinking about maybe
transferring some machine learning stuff from Python to F# in (some distant)
future.

~~~
douche
If you are used to python, and think that VS Code is very nice, you'll be
blown away by the tools and functionality that proper VS offers.

~~~
narimiran
> you'll be blown away by the tools and functionality that proper VS offers

I've used PyCharm before, but currently VS Code seems like the right balance
for my needs.

------
gilgoomesh
F# is very popular, for a functional programming language. In 2014 it was the
most popular functional programming language on the Tiobe index, excluding SQL
(in the latest index it has dropped below Scala, Scheme and Prolog).

However, functional programming languages are not highly popular. Most
programmers never learn any functional programming languages, choosing instead
to learn one of C#, Java, C++, Javascript and stick with it indefinitely. For
that reason, F# is stuck in a position of being the number 3 .NET language
under C# and VB.NET.

That final point is a different topic again: F# is under VB.NET. Few consider
Visual Basic to be a great language; it survives on momentum alone. F# is
comparatively new; momentum takes _decades_.

~~~
AstralStorm
This is mostly because you can do decent functional programming in any
language. Including C (though not as nicely). It is a different approach which
does not really require much beyond having functions be first class object. It
is even easier in OOP ones.

Now if you're talking generic functions and higher order functions, maybe. But
those are rarely needed, as you rather want a tuned specific version instead -
or a template.

------
DanielBMarkham
I love F#. Switched over from the other .NET languages as soon as it came out
and I haven't looked back. F# helps me to become a better programmer.

What's wrong with ti? I wish F# had more OCAML to it. Functors would be cool.

Why isn't it more popular? Sad to say, most programmers don't really care
about being a better programmer. They care about getting a job, keeping a job,
and getting promoted -- none of which might involve learning a functional
language.

To be fair, there's also a different paradigm programming functionally with
larger development teams, a skill that many shops haven't mastered. Three guys
in a startup would be fine. Three hundred guys in a mid-sized firm could have
a lot of problems switching over. I grok that.

I'm kind of surprised F# is as popular as it is. Microsoft deliberately
downplayed it when it came out, calling it a "scientific" language. I think
that coders realize the open source power the language brings to *nix boxes,
the more popular it'll get.

Let's put it this way: there are a ton of other languages I've wanted to try,
but so many of them just aren't "done" yet -- there's still a crap ton of
things missing. F# isn't like that. You pick F# up, you can code just about
anything, and the community is there for support. I don't see that advantage
changing any time soon.

------
1123581321
I "like F#" but there are a few layers between my having some fun a few times
a month and a business adopting it.

F# makes sense when a) functional programming has a history of being
advantageous in the domain, b) there is a mandate or clear advantage to
develop in the .net ecosystem, c) a founder or engineering team has serious
expertise with F#. Even then you have to ask if a functional-ish C# codebase
you can easily add 50 developers to if needed is good enough.

------
sametmax
Functional languages are less popular. They are harder to learn and to use.

Proprietary platform are less popular. And .net is was very closed at the
begining.

Non cross platform languages are less popular. And mono is not really that
great on linux.

Plus the usual communication, timing and hype factors.

~~~
illuminati1911
I disagree. Functional programming languages are not harder than for example
OO-languages. The thing is that people usually learn procedural or OO
-paradigm first when they start programming and moving on to FP requires a
mindset change.

~~~
sametmax
Recursion is harder than iteration. Immutability is harder than mutability.
Callbacks, dependancy injection, and implicit loops are hard to wrap your head
around.

Oop is just a strut with functions and a fancy dress. It's not really a new
way to think.

I trained many, many, many people in small groups in programming. The
functional concepts are always the hard ones to explain.

And as a dev, even when i deeply understand the benefits of immutability, i
find it often being a huge constraint for the most mundane tasks.

Most programmers make simple programs. They don't need complex tools.

~~~
gagege
I think you're forgetting what it was like to learn your first programming
language. A lot of concepts in procedural programming and OOP are hard to wrap
your head around at first (static, by ref or by val, the difference between
base classes and interfaces).

~~~
sametmax
You don't have to learn any of this in python, ruby or php. Oop or functional
doesn't need to mean low level.

Lower level is harder no matter the paradigm.

The features I mentioned are functional no matter the level.

~~~
lkitching
Neither callbacks nor dependency injection are functional concepts, and
implicit loops are pervasive in Ruby (and non-linear control flow in general).
OO in Ruby is quite a long way from structs + function pointers.

------
pella
"Why Isn’t F# the King of .NET?" (Aug 21, 2016 )

* [https://hackernoon.com/why-isnt-f-the-king-of-net-2a9a1963e0...](https://hackernoon.com/why-isnt-f-the-king-of-net-2a9a1963e087)

* HN: [https://news.ycombinator.com/item?id=12530265](https://news.ycombinator.com/item?id=12530265)

~~~
narimiran
Thanks for both links! It'll be interesting to see if something has changed in
public opinion in last 9 months.

------
pkese
I think the main problem is that F# never went beyond .Net platform (e.g. they
never released a native compiler). .Net is nice and gets the work done, but
the fact that existing .Net libraries are OOP style means 1) they don't fit as
nicely into the F# paradigms (see other people's answers) and 2) adoption is
easy for people already familiar with .net and not as easy for people coming
from other languages/platforms.

In addition, inside the .Net world, F# got a role of just "And you can even do
functional programming in .Net if you like", rather than "this is a proper way
of how people should write safe high-level code". I think Ximian is the only
one giving F# proper handling.

~~~
pkese
It might be worth also looking into ReasonML, which is a very similar
language, but gets some of F# issues right, like:

    
    
      - Targeting native compilation and javascript transpilation out of the box
      - Proper functionally architected libraries
      - (including React and React-native for GUIs)
      - Ocaml style functors
      - Easy syntax for people who are familiar with javascript
      - Prime-time promotion by a large company (Facebook)
      - Targeting unikernels (i.e. MirageOS) makes it geek/buzzword compliant
    

The only downside for ReasonML right now I guess is that the tooling and
developer experience (especially on Windows) is nowhere near to what F# / .Net
core / VS Code+Ionide already offers on all platforms (Win/OSX/Linux).

------
keithnz
I spent a bunch of time using F#, and it is good, but C# is a seriously good
language and the advantages of F# kind of turned out to be minimal, and most
annoyingly, not well supported by the tooling.

On the F# slack channel I asked what was the compelling reason for F#, why
isn't it more popular, and basically there wasn't one. There's some stand out
language syntax like computation expressions. The community is really good,
but F# specific libraries are very quiet, web libraries like suave are ok, but
kind of lifeless.

More interestingly, when I shifted a bunch of F# projects to C#, it was
relatively straight forward. C# has enough syntax to do a lot of things
functionally (though not as concise)

~~~
daxfohl
I think this nails it. C# is a really good language. F# has some advantages,
some disadvantages, but there's not much clamor for something better in the
dotnet world.

Java and Objective-C are far behind as languages, so the motivations for
Scala, Clojure, Kotlin, Swift were far greater.

~~~
dragonwriter
That's part of it, but I think the fact that "the .NET world" is largely
enterprise, with is both less sensitive to language quality and more averse to
change (whatever quality it brings) than much of the rest of the dev world is
also a factor.

~~~
keithnz
do you have an evidence for that? It seems a weird thing to say when C# is
such a high quality language, and C# (and .net) keeps adapting and changing.

There are some advantages with stronger functional languages. Though C# seems
to be slowly but surely working out how to incorporate more functional ideas.
Though never will be a "functional language" but will support a functional
approach.

------
wayn3
javascript is insanely popular and its obviously shitty. popularity correlates
very lightly with quality.

~~~
neoeldex
What's so shitty of javascript? From what I've heard is that people's opinion
has changed about that. Javascript is evolving, and so is the ecosystem.

~~~
JepZ
At its core Javascript is a good language. Some of the problems come from the
fact that at its core it is a functional language, but for years it was
marketed as object oriented. And when you look at the language and expect
something object oriented or procedural then you will see a very bad language.

Another aspect is the fact that many of the Javascript's problems were
actually not problems of the language itself but of the environment around it,
like DOM and AJAX implementations in different browsers.

Besides those major problems, the language itself has some minor problems. But
as you pointed out the language has a very active ecosystem around it, which
creates at least 5 solutions to every problem. But many solutions involve new
languages which compile to javascript. So practically the problems are solved
but the theoretical use case of writing plain Javascript is still a little
problematic.

~~~
AstralStorm
At the core JS combines dynamic and weak typing.

It is not even object oriented, so instead it is commonly used with the
prototype approach.

It is not a functional language either as functions can define global
variables, therefore they aren't actually functions. And defining global state
is the default behaviour.

------
DennisP
While I was doing .Net (up until a couple years ago) I really wanted to use
F#. But:

\- Microsoft had no real support for using it in web projects.

\- Functional programming would be great for data transforms in SSIS but that
wasn't possible either. You'd think with a common VM you could use any .Net
language, but no.

Microsoft has always treated it as a non-mainstream language, saying "do the
regular stuff in C# and use F# for the hard stuff." The problem is that C#
isn't terrible for hard stuff, and if you spend most of your time using C#,
then for you it's probably better.

------
robinduckett
Because it's a really hard chord to play on Guitar.

~~~
dsschnau
"If you want to rock out, rely on F#" -Tom Morello

[https://youtu.be/aJXzY9vhqZg?t=339](https://youtu.be/aJXzY9vhqZg?t=339)

------
brudgers
Partially because there is Ocamal. Not that it is (or is not) a better
language. But because it is older and was historically available on more
systems and covers some of the same ground as a descendant of ML. Partially
because of Scala which also covers some of the same ground...though not
claiming as strong a tie to ML it has strong ties to the JVM.

Finally, there are many very good languages. Few are as a popular as
Python...one might say even Python isn't as popular as Python, if you know
what I mean...anyway, I'm not a big fan of the concept of "functional
programming languages" because functional programming is a way of programming
and most languages can be used imperatively or functionally and though some
make it a bit easier than others most programming languages readily facilitate
both. Once it was all the rage to talk about Python as a functional
programming language (but making map/reduce/filter second class citizens in
the past few years has hurt that story) and there are plenty of resources for
functional PHP.

------
lobrien
Since you're "coming from the Python world" you have a good case-study in how
a bunch of things outside of language design are crucial. Python has
essentially won the race to be the next major language among scientists and
that's tied up with a virtuous circle of libraries for, e.g., numerics,
statistics, data viz, machine learning, and even within many scientific
disciplines (e.g., astronomy). The virtuous circle also includes learning
resources (books, Websites, conferences) and the ability to have someone check
/ talk over your code.

For what it's worth, F# is trying to get that same virtuous circle rolling,
but there are a few areas (cross-platform dataviz, interactive notebooks)
where F# just doesn't have quite as good a story as Python.

------
dvfjsdhgfv
I do mostly server-side stuff. Practically speaking, for the most part it
means Linux programming. Unfortunately, .NET is still a second-class citizen
under Linux. Yes, several people report they are using F# without problems
under Linux, but I encountered several glitches in the past and don't feel
like experimenting until things become more mature. I'm lucky enough to make
the choice of the language myself, and I'd give F# a try, but after huge
memory leaks and other problems with .NET on Linux a few years ago I got
burned and would need a good argument to switch now. There are far better
alternatives under Linux (both functional and non-functional)

~~~
keithnz
F# seems quite popular in linux/mac using mono .NET, I was quite surprised in
the F# forums how many didn't even use windows. I actually used my Mac for a
lot of F# coding. But the new approach from MS for cross platform is .NET Core
which (maybe next year as it seems a bit messy at the moment) will be a great
cross platform choice.

------
wcummings
This is a good question IMO. As functional languages go, it seems like it
should be pretty appealing, especially now that .NET is starting to open up a
bit. Good runtime, vendor support, can leverage .NET libraries.

------
rubber_duck
IMO the biggest thing with F# is that all the improvements over C# are
incremental.

Almost every cool feature about F# you show to a C# developer he'll go "OK I
can sort of do that in C# it's just a bit more tedious".

When you add up those incremental improvements you get drastically shorter
code but that is not immediately obvious and that's why you'll have a hard
time convincing C# developers switching to F# is worth it.

Also F# has it's own warts, like compilation order based resolution :(

------
jetti
I'm a professional C# developer and while I have dabbled in F# it isn't where
I ended up when using functional programming languages. I ended up with Elixir
and the main reason why is moving off of the .NET framework. There is nothing
wrong with .NET but after doing it for a living for 5 years I wanted a change.
I really enjoy Elixir and can't see myself going "back" (I was never fully
there) into F#.

------
eof
I like the idea of F#, but do not like programming in the windows ecosystem. I
spent years learning/writing haskell (though I write mostly JS these days).

------
amriksohata
For the same reason most functional languages never took off, they look
succinct, but come back to your code in 6 months and its like a war zone. Also
not to mention the fact that if you start writing your code base in a niche
language that few people want to write in, then it will be very difficult to
recruit and you're stuck with a codebase no one wants to write in, you might
as well write in Cobol.

------
hacker_9
I used F# for a time and ended up disliking it. The syntax is poor IMO and
some bits are quite quirky. I love using Clojure though for functional
programming. Most of F#s ideas come from the Lisp world anyway, but they also
tried to shoehorn on a type system. It doesn't work that nicely in the end,
and I don't think you get the full power of functional programming because of
it.

~~~
UK-AL
F# is basically .NET Ocaml which relies heavily on its type system. I wouldn't
compare it to LISP, except for that its functional.

it seems to me you're just not a fan of static type checking.

------
plinkplonk
(I'm an experienced functional (Haskell) programmer)

I have no interest in F# because I don't want to work in Windows (and the
dotNet platform in general).

Yes I could probably make F#/dotNet work in Linux, but at that point I have
Haskell, (and SML and OCaml and Erlang). Net, net, in my dev/deploy
environment, F# confers no benefit (as compared to the alternatives)

~~~
pkese
Funny. I'm also love Linux, but for me, the combination of .Net Core/Standard,
Visual Studio Code and Ionide provide by far the best programming
toolset/experience of anything I have ever seen in my 30 year programming
career.

And all of it works on Linux just as well as it does on Windows.

------
nunez
functional languages in general aren't very popular in the enterprise yet.
this means that finding talent for more obscure languages like F# is really
challenging. You would need some really large org that's willing to make the
switch to build a hiring pool around it.

which brings me to my next point. the cost of switching languages is really
high for most companies and often times the need to do so is driven by a
direct business need (like Jet.com and their order processing engine, which
ran on F# from the start).

Also, C# and to some extent Java are getting some functional-like features
(type inference, anonymous functions, pattern matching), so the need to take
on a new language entirely to get those features is even lower

------
fsharp-fan-18
Combination of many reasons. See also OCaml. Not the main language of its
platform. No killer app. Most use cases better served by other languages.

It's sad because F# is a fine language. Just not a popular one.

------
mtw
Is there a practical use case (deep learning, cloning Uber, trading, bitcoin
mining, healthtech etc.) where F# or a F# framework is significantly better
than what's out there?

~~~
lobrien
I prefer F# as my day-to-day, but I can understand why, for day-to-day
challenges, a lot of devs might look at some language features and say "C# has
something that's pretty similar." However, use-cases that can be solved
elegantly by pattern-matching, type providers, and/or computation expressions
are areas where the "C# is good enough" argument is harder to make.

One set of use-cases where pattern-matching are particularly valuable is
parsing and other times when you're deconstructing / transforming a complex
structure.

One use-case for a type provider would be, say, taking an XML schema and
exposing its structure as a compile-time constraint.

One set of use-cases where computation expressions are valuable relate to (oh
god I don't want to use the "M"-word) the creation of a small DSL that
isolates some type of specialized computation on a parameterized type. For
instance, the (built-in) `async` computation expression.

Those might sound like fairly esoteric use-cases, but they're really not that
uncommon if you do DSL / library development.

------
dsschnau
I worked with it and while its technically a probably a good language it's
nowhere near as easy to get shit done with it as C#.

~~~
daxfohl
I disagree with this. As someone with over a decade of C# experience and a few
years F# experience, I'm more productive in the latter. However it did take
about two years to get to that point, and the productivity difference is only
marginal. So if you account for the ramp-up time, this is probably true.

~~~
lobrien
I'm no believer in silver bullets, but I wonder about "the productivity
difference is only marginal." For one thing, I think being an F# dev is likely
to improve one's OOP code (immutability by default, smaller methods), so while
I agree that it might feel like one is similarly productive, I think one
changes one's baseline.

For another, I think it really boils down to maintainability. Elsewhere in
this thread, there is a comment that "return to your code in 6 months and it's
incomprehensible." As a guy who worked with a large Scala codebase, I totally
"get" that, but the thing with "functional code you haven't seen in 6 months"
is: It's either incomprehensible or it's MUCH easier to reason about than
stateful OOP code. And the "incomprehensible" stuff tends to fall into a
couple different categories (lifting and conversion, complex function
composition, etc.) that gets at least a _little_ better once you've hit your
head against them a few times.

------
bbcbasic
I think it's two things.

If you write a lot of F# then if anyone leaves you need to replace them and
it's harder than finding a C# developer.

Secondly most of the libraries you interop with are C# and so you have to go
through interop which is more annoying.

~~~
jmcomets
What's surprising is that Scala/Java basically has the same issues, but Scala
seems to be more popular due to early adoption by several industry actors
(Twitter IIRC).

~~~
daxfohl
Scala is also far closer to Java than F# is to C#. You can write Scala code
that looks almost exactly like Java code.

