
The Problem with F# Evangelism - asp_net
https://thomasbandt.com/the-problem-with-fsharp-evangelism
======
nickpeterson
This article retreads common complaints about the F# experience for outsiders
that I've seen numerous time. I'm going to go a different direction.

The problem with the F# community is that they keep asking how to convince C#
developers to use F#. I'm convinced that is not the right way to grow the F#
ecosystem.

Most C# developers tend to come from enterprise and have a set of values and
practices that is generally at odds with open-source, functional languages.
They are used to producing codebases that can never be open-sourced, using
tooling provided by a single vendor. They don't tend to be the ones
contributing interesting or new libraries. In fact, this is a large issue with
.NET in general. Most strong libraries are spiritual or literal copies of
something from the JVM world.

This urge hurts in other ways. For instance, Don Syme has indicated he doesn't
want to put things like Type Classes or Dependent types into the language
because it adds a cognitive load to the language that's hard to balance vs the
gains in productivity. But their absence means that many of the dev's you
actually want contributing to the ecosystem, just use other languages. They
adopt Haskell/Idris/Scala/whatever and start contributing blog posts, tweets,
libraries, conference talks, etc.

I actually think a large part of this decision is that many of these things
would make F# pretty incompatible with C#, which is trumpeted as a feature,
but again, it waters down the language to the point that C# dev's look at it
and say, "Why bother? It's compatible like VB is, so C# can already accomplish
the same things." And in the meantime, it prevents new features that would
attract others.

What sounds more enticing to developers, "More Functional C#" or "Haskell With
Better Tooling"? What's more, there are even examples of how some of these
features could be implemented (both Type Classes and Dependent Typing exist in
some capacity through feature requests and F*, an experimental Microsoft
language).

Basically, F# should be more about being different than the rest of .net, than
trying to be ".net through an OCaml set of glasses".

~~~
rubber_duck
I disagree with this, you can sell F# to C# developers - things like type
providers for SQL checking their query strings in compile time and no extra
build step to produce SQL type definitions vs monstrosities such as Entity
Framework... if they've been burned by ORMs to drop to stuff like Dapper
they'll love F# type providers.

Immutable data is also becoming a common pattern even in C# but it's tedious
as hell to write.

Functional programming is also seeping in but again tons of boiler plate.

Biggest problem with F# is that it has it's own warts + it's a big upfront
switching cost and a steep learning curve but it offers many marginal
improvements - when you sum those improvements it ends up being worth it IMO
but that's a very hard sell.

~~~
brianberns
C# developers in my shop loathe the SQL type provider because it requires them
to have a compatible SQL Server database schema at build-time. The extra level
of organization required is more than they can accept.

~~~
ice109
that kind of thing is a collosal mistake in my opinion - just on the face of
it I/o at compile time seems very wrong.

~~~
bonesss
An understandable position.

Here's the context that makes it not a big deal:

1) If there is some fundamental issue with having a dev DB then you would just
use another ORM, just like in C#. Really, this specific type provider is not
an ORM, it's for SQL server data munging. Most every project I've seen in a
decade has multiple dev DBs, many used in testing, many used for staging...
being able to talk to a valid schema source should be relatively
straightforward... but if it isnt then get a different type provider or use an
ORM with explicit code generation.

2) Compile time guarantees about data sources is a huge source of comfort when
dealing with DBs owned by external actors or teams. For data scientist,
integrator, sys admins, and such the norm is connecting to operational DBs
that you have very little control over. This specific Type Provider ensures
that your scripts will not compile if there has been a breaking schema change.
That means you're seeing these issues during deployment, not as costly runtime
errors that may or may not corrupt your application state. Less debugging,
more safety, better guarantees, immediate feedback on issues; all in realtime.

To summarize: if compile time validation of JSON structures, XML structures,
SQL Schema, or custom file formats creates some kind of pain, then don't use a
provider of types that relies on analyzing data structures to create code :)

For the other 99.9999% of the time type providers are a DREAM for working with
external data sources, provide most of what we want ORMs for, and are very
lightweight in comparison. It's rapid data exploration with built in
prototyping. Very nice.

------
phillipcarter
I actually work on F# at Microsoft. I've had success and some failures when it
comes to evangelizing F# through Microsoft (but mostly success if my measures
are accurate). I strongly believe that it can be boiled down to one major
thing:

Programmers learn how to program with C-style languages. C, C++, Java, C#,
JavaScript, Python (sorta) . . . they're all in the same family. People,
especially while learning, associate _programming_ with specific constructs
and idioms of C-style languages. It's incredibly difficult to break that
barrier.

I think that functional programming is on the rise, and that more and more
developers are starting to realize that the types of bugs that hold them back
can be reduced by using a more powerful language. But it's got a very long way
to go, because there is a lot of unlearning to do. The article alludes to this
a bit. For example, immutability is one of the key concepts in nearly every FP
language. Functional programmers take it for granted, but it's
transformational and completely changes the way you have to solve a problem.
This hump is often too big for many people to get over, at least in their
first trial with a functional programming language. It's hard to solve a task
you know how to solve when you now need to re-think your approach because the
language doesn't let you change _x_ in-place.

Additionally, I believe that many programmers aren't necessarily aware of all
of the problems they're having. The next time you hear someone say, "and make
sure to check for null here", watch them to see if they're seeing that as a
general problem hurting their ability to get bits out the door or not. In my
experience, it's not usually viewed that way. Yes, null is a necessary evil in
many environments, but it's one that can be tamed, and different languages
have already figured out how to do that. But unless it's seen as a _problem_
by people at large, they won't see that as a carrot when you wave things like
Optional types in front of them.

Overall, I'm still excited. Jet.com is a billion-dollar company that built
their stuff with F#. There are similar stories of companies successful with F#
(and other functional programming languages), and it feels as though this is
happening more often. And as the mainstream (read: C-style languages) adopt
more functional programming techniques, I think this will only get better. I
think that people will see the value, then see a language which does it
better, and give it a try.

~~~
rottyguy
"...realize that the types of bugs that hold them back can be reduced by using
a more powerful language."

I hear this a lot with FP but would love to see some real world examples of
this if anyone has any links.

~~~
tome
How many times have you had the runtime exception

    
    
        AttributeError: 'NoneType' object has no attribute 'foo'
    

(or its equivalent in your favourite language)?

~~~
earthtolazlo
That's something addressed by static typing though. I'm pretty sure any
dynamic language has that issue, functional or not.

~~~
tome
It's fair to say that the boundaries of "functional programming" are pretty
amorphous and I certainly didn't mean _untyped_ functional programming. In any
case, if you want to prevent null/None errors in a way that gives the
programmer his/her own access to create similar new abstractions then you need

* sum types

* parametric polymorphism

* pattern matching

at which point you may as well also add

* first class functions

and then if you don't describe your language as "typed functional" then how do
you describe it?

------
KirinDave
I think F#'s larger problem is that it doesn't dip into many of the wells that
even OCaml (its original inspiration) has dipped into. C# developers are wrong
that C#'s functional facilities are just as good, but it's a big struggle to
point to a place in F# and say, "THERE! THAT IS THE BEST BIT!" The closest I
can get is type providers (which are cool and I wish for them elsewhere) but
they're kinda specialist.

Ocaml folks have these. Haskell folks have these. Heck, even psuedo-functional
languages like Clojure and Scala have these.

The other problem is one of tooling (disclaimer, last time I tried this was
just over a year ago). F# not only has pretty obscure tooling, but in
conventional tooling it introduces a total linear order to your entire source
tree, and it's one YOU must maintain with a GUI list. What's more, the F#
community is very keen to disseminate the language.

I think F# would be more popular if it did more to differentiate itself from
imperative programming. There is a longstanding argument that this is
"unfriendly to data scientist", but I'm really not convinced by this, as I
meet very few mathematicians outside of the stats world who don't on some way,
shape or form espouse functional programming.

~~~
sremani
Tooling wise, tried Rider IDE from Jetbrains on Ubuntu, and out of the box it
works (if you have mono + F# installed).

The ionide project is doing tremendous job of support on vscode.

It has improved compared to year, and definitely much better, in a month or
two all the major IDEs including MonoDevelop will likely have .net core 2.0
support with F# baked in (speculation on my part).

~~~
KirinDave
I just don't see a lot of point to Mono in my domain. Even with the code
inputs from .NET I've never gotten anything but sub-par performance from it
for network services.

------
banashark
I usually don't try to sell F# as compared to C# as noted in many other
responses here. Since most of my friends work in other languages I usually
just use python as my reference.

#ME: "Hey that stuff at pycon was pretty cool, huh?"

#FRIEND: "Yeah it's interesting the directions they're going with the
language."

#ME: "Yeah the optional types could help clean up big code bases, and open up
the door for quickcheck-like fuzzy testing."

#FRIEND: "Yeah."

#ME: "And some of the functional programming stuff is pretty neat too, I know
it's easier for me to test."

#FRIEND: "It's so much easier."

#ME: "And the asyncio stuff is gonna be really nice to work with when it
catches on more."

#FRIEND: "Yeah it seems a lot more ergonomic of a solution."

#ME: "And the binary distributable packaging tools look like they might
actually work this time."

#FRIEND: "Probably not, but we can hope."

#ME: "I think I should introduce you to my friend F#."

Then just do some stuff in fsx with a type provider or some other neat stuff
and at least you've got the message across.

People get excited about solutions to their problems. If you start giving them
more problems then you're only adding to the constant subconscious cognitive
load that they bear in regards to software development.

If you show it to them in terms of problems that they already have, you're
reducing the cognitive load. Everybody loves having less stress.

But this is just how I approach it. F# is like Python4 for me.

~~~
DeepRote
Have you ever looked at Julia?

I mention it just because I've had almost a carbon-copy of that conversation
but I showed them Julia and now that person actually is writing Julia for
their startup. That person is doing technical chemical engineering stuff, so
the fit is a bit more pronounced, but I think it's a neat language aside from
that. Parametric types and multiple dispatch and lisp-macros, oh boy!

------
jasim
How can you help someone see the beauty and benefit of Typed FP without asking
them to just trust you and spend a few months with it?

I used to dismiss this as academic noodling till I got tired of OO and started
going back to my procedural roots with just plain functions organized into
namespaces. I was pretty happy with it till the codebase grew to a point I
couldn't keep track of the flow of data. Objects help you to some extent here
since they group related values into one instance, but I didn't want objects
anymore.

This was when I started seeing references to OCaml, especially "Why ML/OCaml
are good for writing compilers" ([http://flint.cs.yale.edu/cs421/case-for-
ml.html](http://flint.cs.yale.edu/cs421/case-for-ml.html)), and also saw a
presentation by a programmer I respected where he built a general game playing
engine in OCaml. Seeing someone use it for practical, advanced programming was
the first catalyst.

Then Jordan Walke mentioned somewhere that he first prototyped React in OCaml,
and shortly after they released ReasonML. The type system was amazing. All
values are typed, even complex nested structures have a type. There are
variants which mean I can express different shapes of the same value using
types, and the compiler will tell me if I ever forget to handle a particular
case of this variant.

I've been programming with Reason/OCaml for about six months now, and Typed
Immutable Programming still takes me more time than just gluing together a
pack of cards with imperative code. But once the code is written, it sits on
an iron-clad foundation.

Most systems as they grow start to fold under its own weight, but here the
accretion of code is an almost unmitigated good thing. It means my system's
cognitive wealth is increasing without an exponential increase in maintenance
cost.

But how can you help someone understand all this in a single conversation? A
lot of people come to this because they worked on systems with pain points
that Typed FP can address. But for most others who haven't had that sort of
clarifying experience, what can you tell them to give it the non-trivial
amount of effort it requires?

~~~
frou_dh
I'm not in the Typed FP world, but I found the concept of pervasive use of Sum
Types making invalid states (according to the project domain) of composite
structures _unrepresentable_ to be a pretty compelling nugget to chew on.

A lot of debugging is: This <object> has ended up in a weird state. Whereas
the alternative could be that if the code compiles then it's impossible for
that <thing> to ever be in a weird state.

------
nlawalker
The problem with F# evangelism is that it doesn't exist. No one is
evangelizing F#; everyone is evangelizing functional programming. F# is the
Python of .NET - it's multi-paradigmatic and you can do whatever you want.
Sell it to people that way, and let them get into functional concepts later,
or never.

F# has a huge opportunity in the enterprise. A ton of enterprise C# code is
not object oriented at all, it's big, poorly thought out clumps of imperative
script wrapped in methods and classes so it can be compiled or fit into the
framework that's calling it. Sometimes it'll get a quick last pass run on it
to make it "more object oriented", because that's what C# code is supposed to
be; this usually just makes it worse. It's written in a scripting mindset: the
developer needs to get things done, and adds code and bangs on stuff until it
compiles and looks right when it runs in the debugger.

F# is actually well suited to this style of development, but it's hard to find
anything about it, because every F# tutorial, book and blog post is actually
about functional concepts, functional design, functional thinking and
functional programming, including this one.

If you want to sell F# to enterprise developers, show them how they can write
their C# code in it without having to pretend that it's object oriented
anymore, and how that's a _good thing_.

~~~
pjmlp
> If you want to sell F# to enterprise developers, show them how they can
> write their C# code in it without having to pretend that it's object
> oriented anymore, and how that's a good thing.

As enterprise consultant, for the types of customer projects I work with, lack
of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C#
into F#.

~~~
bonesss
Domain modelling in F# is lightyears beyond C#s. Parallel and concurrent
development, not to mention actor systems (F#s built-in or Akka.net), are also
leaps and bounds beyond the C# story. These are Enterprise issues. Identity
management, default immutability, distate for null, and exhaustive pattern
matching are all major Enteprise features that large, complex, and critical
systems see measurable benefit from...

There is no barrier to mingling F# and C# libs to focus on specific tasks or
parts of the app. Having application libraries in C# and domain code in F# is
a common pattern. Particularly at the GUI level, extra-particularly with
anything that uses databinding so your domain types can be used directly.

F# does not get the same amount of tooling love as C# for the "latest and
greatest" from microsoft. If you look at the Enterprise track record of
Microsofts "latest and greatest" since they started pushing ADO.net to present
day... well, I would argue that's a huge benefit. Enterprise customers need
tooling stability and platform stability, so letting ASPvReplacedInThreeMonths
come and go without impacting projects is a big money saver.

~~~
pjmlp
> There is no barrier to mingling F# and C# libs to focus on specific tasks or
> parts of the app.

Try that on .NET Native apps.

> F# does not get the same amount of tooling love as C# for the "latest and
> greatest" from microsoft.

No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a
productivy drop.

~~~
dcdcdcdc
I'm not a C# programmer, but it seems to me that the productivity drop
argument is weird. Your engineers might be in a local maximum, and it might be
worth the _temporary_ productivity drop, if in the long run it would allow
them to reach new (and better) heights. This, of course, is an outsider's
supposition, and I understand that you're just conveying their point of view.

~~~
pjmlp
How it is weird having a productivity drop when everything that is done
graphical by tools with a simple mouse click, must be done manually in plain
code without any kind of visual assistance, beyond "compile and see how it
looks like"?

~~~
dcdcdcdc
No, I meant that bringing this fact as an argument is weird: I'm not arguing
that there's a productivity drop, I'm saying that it's only temporary.

Furthermore, I have a few years of RAD development experience, and I know as
well as you do that not everything may be coded with a couple of mouse clicks.
As soon as you hit the business logic, you need to use the keyboard, you need
to devise algorithms, you need to evaluate their complexities, and you need to
code them down.

That being said, even just getting used to a new language gives you new
insights about coding practices.

------
AnimalMuppet
I'll go a step further. There's a problem with _language_ evangelism.

There is no "one best language" or even "one best programming style".
Functional has worked for some people to address the problems they have, but
not everyone has those problems.

For example: I once worked on a video switcher for TV stations. You have maybe
100 video sources, maybe 80 video destinations, and you can connect any to
any. You also have about six different sources of commands to make
connections. For responsiveness, each source has its own thread. So _the
nature of the problem_ is one giant shared mutable state. The functional
people come along, and they say "shared mutable state is evil; don't do that".
Yeah, well, that's actually not bad advice, but it doesn't help me at all with
this situation, since _I can 't avoid it here_.

There are other places where FP isn't the answer: Situations where you care
about memory layout (high performance computing or just memory constrained),
where one of the main concerns is sequencing (some industrial control
operations, maybe robotics), where predictable timing is important (real time
systems), maybe others.

Use the right tool for the job. FP is not the right tool for every job.
Nothing is. The problem with evangelism is when it says "this is the One Right
Way", instead of the humbler assertion "in some situations, this can help you
with some of the problems that are slowing you down".

Don't get me wrong. FP has a good story. (Even if you don't use FP, learn its
deepest lesson: _Control your state space or die_.) But FP is not always the
answer. Evangelists might get further if they recognized that.

------
d--b
F# problems from a C# developer point of view:

#1 tooling: visual studio integration of F# is poor. You don't get cross
language usage reference, so you lose all the benefits of static typic.
Projects and references are a mess. Being primarily a scripting language, it
feels like a toy language

#2 compatibility with C# is poorly done. That F# functions cannot be consumed
as C# lambda is a real mess. Boxing / unboxing doesn't feel FP ish at all. You
often need to implement classes with interfaces to interact with C#'s core
libraries.

~~~
phillipcarter
> #1 tooling: visual studio integration of F# is poor. You don't get cross
> language usage reference, so you lose all the benefits of static typic.
> Projects and references are a mess. Being primarily a scripting language, it
> feels like a toy language

Could you clarify what you mean here? Although things like Go to Definition
and Find all References don't work across C#/F# boundaries (yet), but you
absolutely get IntelliSense and the benefits of static typing. F# isn't a
scripting language, although it does support F# scripts.

~~~
d--b
You get intellisense alright. But using C#, I never need to #open the
namespaces myself for it to find the types I am using or the extension methods
I need. (Maybe this is because I use resharper, but still, it really slows me
down).

Also the benefits of static typing are that it makes it easy to refactor. Here
if I change things in C#, I need to grep my F# scripts for usage, it's a real
pain.

~~~
phillipcarter
> You get intellisense alright. But using C#, I never need to #open the
> namespaces myself for it to find the types I am using or the extension
> methods I need. (Maybe this is because I use resharper, but still, it really
> slows me down).

This is actually added in F# tooling for VS 2017! Both via a lightbulb code
fix and with IntelliSense itself. If you have a reference to a .dll with
symbols, the IDE can suggest an _open_ statements for you.

------
sremani
Not pertinent to the article but I guess to the people interested in this
discussion.

The first in person F# conf in North America (to my knowledge) Open Fsharp
Conf. is on Sept 28, 29 in SFO.
([http://openfsharp.org/](http://openfsharp.org/)).

My only association is I bought ticket for it.

------
maxxxxx
Good article. F# would find much better adoption if there were more FP style
libraries out there. I have tried to move to F# but it's a real uphill battle
when pretty much all sample code and most libraries are in C#. I would do it
if I was alone but it's hard to convince a team of the benefits.

~~~
201708throw
The problem is F# does not have a killer feature it has a list of nice
features. Examples of killer features: Akka, RoR, browser monopoly.

------
sitkack
The best way to get someone to tune out when you are trying to convince them
to get out their _._ bubble is to casually introduce words that they don't
know.

By doing this, you separate yourself from the listener, giving a clear
delineation between the noob and the l337 wizard.

It also helps to feign surprise, "you dont know about monadic entropy lenses?"
or use the word _just_ as in "Just run the parser combinator in reverse, its
easy".

~~~
KirinDave
It's unfortunate tho, because for example what word do I have for the
generalization that we call "profunctor" other than a profunctor. Even the
words we use to describe a profunctor are "contravariant and covariant" and
these words OUGHT to be more applicable to programmers but are not.

For many programmers, the axioms of what a function are (a calling point to
code which is contravariant in a product and covaraint in a single return
value), what objects are (a unique closure over functions values with a
syntactically supported lookup of named values and a system-provided identity
function) are so unvarying in their experience as to be synonymous with the
word we use to describe it without needing further quantification. That gets
tricky when you want to say, "Ah, but this unique way of thinking about this
datatype lets us pretend it's a function and then we need to talk about what
it needs and what it provides in more general terms."

Since functional programming is actually all about completely tearing down the
world to everything but a series of functions, it's unsurprising it needs
different words.

Finding a way to entice users to join in the functional party is really
difficult because asking a programmer to do it is roughly akin to asking them
to learn to program again. And don't get me wrong, I think you emerge from the
other side of it better and more productive in every way, but it's difficult
to prove that and more difficult still to convince people of it.

~~~
sitkack
We can sell the vision without sound like a Pythagorean-cult of mathematics
(functional programming). Hell, once I showed some of Python programming
brethren pure functions they were hooked, HOOKED I tell you!

When I showed how to make an object system using closures, they were like,
"Cool!"

Some people start with the math, some people finish with the math and others
deny the math. But we can all be better programmers with functional
programming. If our goal is to educate, our actions should be the opposite of
alienation. Some people gravitate to FP because it is seen as hard, as bad-ass
and want to show their mastery to others. Those people should probably not be
teaching FP.

~~~
KirinDave
I think a disagreement about didactic methods and ordering is not what I was
addressing. I just think at some point calling it a "Pythagorean cult" (and
what, I wonder, are we murdering people over uttering?) is counter-productive.

I'm slowly recording several sessions, and I think about 2 hours in enough to
introduce Purescript, explain the basics of Functors, Applicative Functors
(which come nearly for free), and even explain, motivate, and use monadic
functions. But I don't know how to do this without at least giving folks some
words (Functor is a name as good as any, and every other name for Monad is at
last as if not more intimidating

It's just at some point if we observe the shape of what we're doing, we can
generalize in a useful way further (e.g., the lenses-banannas-parethesis
approach).

------
pjmlp
I lost faith in F# the moment Microsoft decided it is not worthwhile to delay
Visual Studio 15.3 to properly support it pushing devs to VSCode, and the lack
of roadmap for .NET Native/UWP.

So first make F# a first class citzen on .NET and maybe many C# devs will look
again to it.

------
MichaelGG
Microsoft promoted this idea that F# is for mathematicians and engineers, so
its no wonder that people pick this up. And I'm not sure who is pushing this
idea that F# is not fine for OO work. It has all those features. So starting
with F# as a "better C#" \-- there's nothing wrong with that. Over time I
think people will come to view OO as suboptimal, but in the mean time F# is
just a better language to use than C#.

MS hasn't funded F# enough, and has crippled the marketing on it to continue
to push C# rather than admit they've made mistakes. The tooling issues and
other random incompatibilities are why I don't use it as much as I used to -
it's too much friction.

~~~
toyotaboy
No one who knew what they were talking about at Microsoft said F# was for
mathematicians and engineers. It's a myth pushed by C# programmers and idiots.
It's nonsense and you shouldn't repeat it.

People at Microsoft repeatedly said "Simple Code for Simple Problems". C#
programmers don't like repeating that.

~~~
MichaelGG
Doesn't matter if they didn't know what they're talking about, that was what
was written on the Microsoft sites when comparing C#, VB, F#. F# was always
pigeonholed into scientific and financial categories, never aimed at general
code.

I'm only repeating it to point out that MS itself did poor marketing for F#,
clearly favouring C#.

~~~
toyotaboy
Microsoft didn't promote that idea. Some random people at Microsoft did, a
very long time ago. Just forget about it and move on.

------
jmull
F# isn't generally solving problems... well, it can but rarely at the same
level as it introduces problems.

People can have awfully cavalier opinions about switching languages, but it's
a very heavy-weight change with strong implications for existing code, dev
training (new syntax, new patterns, new pitfalls), available frameworks (often
resulting in more new patterns), technology stack (which can reverberate out
to testing, scalability, etc.)

Even if you assume F# is only better than C# and in no way worse, it's usually
major investment to switch... typically at least an order of magnitude bigger
than that bullet list of ways F# is better than C#.

------
tcard
A great take on this topic is a talk by Evan Czaplicki, creator of Elm,
another functional language: Let's be mainstream! [1] The conclusions are more
or less the same than the article, but Evan goes into a lot more depth. And in
my opinion, as a result, Elm does very good in this regard.

[1]
[https://www.youtube.com/watch?v=oYk8CKH7OhE](https://www.youtube.com/watch?v=oYk8CKH7OhE)

------
zubspace
Good post. I really hoped for some f# code after listing all those scenarios
where c# fails.

Anyway. I work in a c# shop with a large monolithic code base developed by a
small team with lots of fluctuations over more than 10 years. I have no
functional programming experience at all.

I love c# because we actually try to keep the code as simple and linear as
possible and only introduce complexity in certain areas if performance
requires it. Yes there are hacks and dirty code passages, but if you stick to
basic code constructs they are easy to decipher.

If your facing more than 10 million lines of code you start to appreciate
simple code. Moreover if different developers, which come and go, are working
on it. Living without refactoring and inspection capabilities of resharper is
nearly unthinkable to me.

Now, how would you convince someone like me to try out f#?

There are only drawbacks: Obscure things we would need to learn (type classes?
monads? xyz?). Probably hard to read, 'clever' code. A mixture of c# and f#.
Unknown library, build and deployment issues. And I guess, f# developers are
rare around here.

Even after reading this post, there's unfortunately no convincing reason for
me and management to give f# a try...

~~~
jasim
I'll tell you my experience. I never liked the arguments about reduced bugs or
concise code. As a programmer the reason I would use F# (or OCaml, or Haskell,
or Elm, or PureScript) is because it increases by day-to-day well-being.

I'm happier writing Typed FP because the system is very concrete in my head as
I work with it. In a dynamic language, there is always a nagging uncertainty
about the system - if you're using dictionaries to pass data around, you don't
have certainty in what keys it'll have, and what data will be available inside
it, and what could possibly be null.

When you add a new kind of a domain object (a Guest user in a user management
system for example), you have no idea where all you need to handle it. You fix
the obvious places, and do a text search, and find a few more. And the rest
you fix over time.

The runtime robustness of untyped systems in my experience generally is a
function of time. The more it sits in production, the more bugs we discover in
the most commonly trafficked codepaths. We fix them - duct tape works - and
then it sits and chugs along. (Robustness to change is another matter
altogether).

But if you use a Typed Functional language, when you introduce a new domain
object the compiler will tell you exactly where they are being used and will
refuse to compile till you've made sure you're handling it in all the right
places.

Value-based programming (ala Immutability) lets you write code as if you were
writing mathematical definitions (high-school mathematics; no category theory
or monad). While we can be disciplined about not writing mutating code, there
is a real difference between 99% confidence and the second-guessing it
entails, and just not having to worry about it at all. Everything is a value.
There are no objects/references.

All this adds up to a state of clarity when you program. You don't have to
keep second guessing yourselves; you don't have to do defensive checks that
makes you feel a little bit ugly inside; you don't have to deploy worrying
about the unknown unknowns that can break your system.

~~~
nurettin
In Delphi, I hide this kind of complexity behind methods which check
everything for nulls and types at runtime. I imagine I'd do the same thing in
C#, too. So if I have json = TJSON.parse('{}');
json.Node['something'].Nodes[0].each(procedure(pNode: TJSONNode) begin;
list.add(pNode.GetValue<int>()); end); { Nodes and Node properties actually
create empty nodes and keep a debug string to show you where exactly your code
failed so you can go back and take a look at which assumption was wrong. I
then cleanup everything when the main node is freed.

So my point is; it all depends on how you code something, the language may do
it at compile time to prevent runtime assertions, but that also comes with
extra baggage (I assume you need to write more code to define your types,
function call conditions and mappings)

------
systems
I honestly don't think there much wrong or a problem with F#

I do follow F# somehow, and compared to other languages .. it actually seem to
have a very pragmatic and active community

The F# community build a lot of interesting frameworks, suave, websharper,
type providers ... to name a few

I dont think, anything will look popular, when compared to Java , C# or Python
.. but compare it to Haskell, Ocaml, Clojure.. Dart, D, Nim .. and the
plethora of languages that compile to javascript , and you will see F# is not
doing so bad

~~~
systems
I will just make one criticism ... it is sadly somewhat awkward to install F#
even on windows

and they do need a good ide

if you go to the F# .org site, installing F# without installing visual studio,
is a 4 step process .. and when I tried it on windows 7 it just didnt work for
me

i eventually gave up and install visual studio on linux, thing seems better,
but .. still missing a solid ide

~~~
talyian
The first class IDE for F# is VS Code + Ionide. The language service backend
for F# is also very well supported for emacs.

~~~
TensorMetric
The first-class IDE for F# is the full Visual Studio, not VS Code + Ionide.

~~~
toyotaboy
VS Code is now recommended by Microsoft for F# + .NET Core. Get with it,
you're behind the times.

~~~
TensorMetric
It's only recommended temporarily, until the issues get ironed out. It doesn't
make it THE first-class F# IDE.

------
sklivvz1971
The problem is that people who are drawn to F# tend to be a certain kind of
people: generally stronger in CS, but also more prone to think that changing
programming language is a solution to a wide variety of problems.

Many people are not like that, and stuff like a small community, worse tools
and toolkits and less programmer availability are actually a huge deal,
capable of tanking a good project, whereas having a 10% better language isn't
a huge gain.

It's that simple.

------
magnumkarter
For me, I only got into .NET because of F#, and even then I pretend C# doesn't
exist. I tried learning OCaml, it has cool features, like parametric modules
and GADTs. But I always ran into the issue of irreproducible builds. This
didn't happened in F#.

I eventually tried F# because it was close enough to OCaml and while I was
learning OCaml I always referred to this site
[http://fsharpforfunandprofit.com](http://fsharpforfunandprofit.com)

I'm definitely an F# evangelist at work, but we are not a .NET shop. But I was
would say that the introduction of ML features in other languages, (Swift,
Rust) are good for F# evangelism, because it makes these concepts more
familiar. I think the focus should be on moving F# away from .NET because F#
itself, it is much more accessible that its cousins OCaml and Haskell. And if
Microsoft won't give proper support, the community should move to other
platforms. Some discussions are already happening here
[https://github.com/fsharp/fssf-ask-the-
board/issues/4](https://github.com/fsharp/fssf-ask-the-board/issues/4)

~~~
pjmlp
The difference being that Apple is quite vocal that Swift is the future of app
development on their platforms, while Microsoft is trying to push UWP as the
future of Windows apps (supported languages VB, C#, C++ and JavaScript).

~~~
yawaramin
UWP supports JavaScript? Cool, in that case a bunch of transpilers should work
(once bindings are written) ... people can just use their preferred languages:
OCaml/BuckleScript, F#/Fable, TypeScript, PureScript, et al.

I've actually written and run JScript scripts on Windows Script Host with
BuckleScript, it's really nifty. You write strongly-typed code and get a JS
artifact that can run on your target platform. For the curious, an example:
[https://github.com/yawaramin/wsh-bs-test](https://github.com/yawaramin/wsh-
bs-test)

------
alkonaut
Businesses and developers generally won't switch languages. Evangelism makes
people curious which means new businesses and new projects some times picks a
new language.

I'm a C# dev since 14 years (single project) hoping my next project will be an
F# one. That might mean I have to switch jobs - and I hope there are enough F#
shops when I need one.

------
macca321
We're singing from the same hymn sheet

[https://github.com/mcintyre321/OneOf](https://github.com/mcintyre321/OneOf)

[https://github.com/mcintyre321/ValueOf](https://github.com/mcintyre321/ValueOf)

------
strayamaaate
I’m a C# developer, love the language and how easy it is to express what’s in
my head as code.

I recently had a chance to play with F#. After being completely lost for a
bit, I found I had to really rethink how I was reasoning about problems and
the right way to solve them.

But that’s the point I want to make. I don’t expect to be good at FP for a
while - it’s going to take time to grow, along with the tooling and community.
But I appreciate having a way of framing a problem differently, and like the
direction F# is headed.

It doesn’t mean I’m going to drop C# any time soon, I’ll likely just use both
- e.g. my more math heavy libraries will be F#, and my networking and Web API
code in C#.

------
galkk
I think that the problem with F# is that it feels more or less abandoned by MS
itself.

It's already F# 4.x, but I can't remember any significant new features in last
3 releases at least, neither in language nor in the standard library.

~~~
toyotaboy
That's because F# 1.0 was bascially a more powerful language than C# 10.0 (C#
still doesn't have proper pattern matching for example, or discriminated
unions)

For features added see
[https://en.wikipedia.org/wiki/F_Sharp_(programming_language)](https://en.wikipedia.org/wiki/F_Sharp_\(programming_language\))

Named union type fields Extensions to array slicing Type inference
enhancements Printf on unitized values Extension property initializers Non-
null provided types Primary constructors as functions Static parameters for
provided methods Printf interpolation Extended #if grammar Support for 'fixed'
Tailcall attribute Multiple interface instantiations Optional type args Params
dictionaries Struct tuples which inter-operate with C# tuples Struct
annotations for Records Struct annotations for Single-case Discriminated
Unions Underscores in numeric literals Caller info argument attributes Result
type and some basic Result functions Mutually referential types and modules
within the same file Implicit "Module" syntax on modules with shared name as
type Byref returns, supporting consuming C# ref-returning methods Error
message improvements

~~~
toyotaboy
For library, see [https://github.com/fsharp/fslang-
design/blob/master/FSharp-4...](https://github.com/fsharp/fslang-
design/blob/master/FSharp-4.0/ListSeqArrayAdditions.md)

~~~
TensorMetric
All those features mean nothing to seasoned .NET developers when you can't use
the language natively on Microsofts primary application platform.

~~~
toyotaboy
You can gripe about your fav UI stack not being supported just the way you
want (you don't seem to have any other complaints), but your claim the
language is not improving is wrong.

~~~
TensorMetric
> You can gripe about your fav UI stack not being supported just the way you
> want (you don't seem to have any other complaints),

.NET Native and UWP are not just UI,

> but your claim the language is not improving is wrong.

You're confusing me with the parent commenter
[https://news.ycombinator.com/item?id=15029008](https://news.ycombinator.com/item?id=15029008)

------
Joe-Z
I'm currently a C# developer, but have tried functional languages before. As
mentioned in the article, I think a lot of people are satisfied with the
functional capabilities C# already provides. I don't need to write functional
code all the time, but if I can model a problem more elegantly using higher-
order functions I will gladly do that.

I'd be interested to read a more in-depth description of the recent project
which the OP chose to implement with F#.

~~~
mariusmg
Only thing is actually missing from C# now to be a "proper" functional
language is a way to declare (and pass a function arguments) immutable
objects.

------
m_cubed
I built Tsunami IDE. It is a F# IDE. I built it before VSCode or VS Community
came out. I built it as a test to see if cost of Visual Studio was blocking
adoption of F# and the ideas that F# codifies. The experiment was successful,
I got my answer, and the answer is no. Even with free tools people have a hard
time adopting F#.

First let me address those who are asking for Type Classes and Dependent
Types. These would make the compiler too slow. The F# compiler works in the
100s of ms and the 100s of MBs ram. Where Scala is in the 1000s of seconds and
the GBs of ram. People will give up on code completion if it takes more than
500ms and they generally don't like waiting longer than 200ms. Separately
Martin Odersky (the creator of Scala) laments that the more advanced language
features attracted the wrong type of people to the language and flooded the
internet with overly academic tutorials.

I put a lot of the blame for the lack of F# adoption on Microsoft. Part of
this is to do with the Dev Div vs Windows war that almost deprecated the whole
.Net ecosystem. If Windows 8 wasn't such a disaster it's likely .Net would
have been deprecated and would never had been open sourced. (at least
something good came from Windows 8). Part of this war also ended with a lot of
the best .Net people leaving to go to Facebook. This brain drain has really
hurt Microsoft and I doubt they'll ever recover. Most of the old hands that
know better are aging out and the new people at Microsoft don't know any
better.

As for tooling, Microsoft has done and continues to do a bad job with F#
tooling. There is is a not invented here culture at Microsoft Redmond which
includes being hostile to Microsoft Research. Visual Studio is a bucket of
bandaids and it takes an army of people just to keep it going. F# is given a
low priority. It's worse with the latest release because they've gone
overboard with compiler features with the Rosario release and have made it dog
slow and painful to use. I hope they can fix it with updates but who knows.
You can still get older versions. It's very possible to build a really good
IDE around the F# compiler but unfortunately Microsoft refuses to do so.
Thankfully, it looks like there are some good alternatives becoming available.

In comparing Scala and F# adoption, Scala has Hadoop/Spark which is a killer
product that can earn a consultant a lot of money. The fact that C# is a
better language that Java means there are more Java refugees going to Scala
than there are C# refugees going to F#.

Thankfully Don Syme has made F# completely open source. Now with .Net being
open source we no longer have to worry about Microsoft shooting itself in the
foot again.

I make my money writing a product written in F# and can attest that F# is one
of my big competitive advantages. I highly recommend it.

~~~
phillipcarter
> There is is a not invented here culture at Microsoft Redmond which includes
> being hostile to Microsoft Research.

I'm 100% okay with criticism about things and think it's a good when people
voice it, but this is not based in reality.

MSR (and Don) work together with different groups in Azure and and the
developer division. It's not perfect - we are a large, multinational
corporation with the same problems in communication across organizations as
any large, multinational corporation - but calling the relationship hostile is
misleading, harmful to the F# community, harmful to those of us who work on
F#, and harmful to F# growth. I really don't appreciate spreading this sort of
stuff.

------
bernadus_edwin
F# evangelism should start with small thing. Start as library or component.
The main project is still c#. Just like react approach

------
brianberns
I'm the lone F# developer in a shop full of experienced and talented C#
developers. I have clout, but not enough to convince any of them that F# is a
better choice for many of our purposes. It's frustrating, but I try to
understand that people are just naturally resistant to big changes like this.

~~~
maxxxxx
Same for me. Do you think that in the end F# would be that much better for
good C# devs? I am not so sure.

~~~
lmm
Having made the analogous switch from Java to Scala, I think it's the good
devs that benefit the most. Functional languages give you more scope for
factoring out commonality, avoiding repetition, reusing existing library
functionality - exactly the things that make good devs better than bad devs.

------
jimbokun
Very nice list of very practical problems functional languages like F# are
meant to address. After a certain amount of experience, pretty much every OO
developer will have experienced these problems, so makes for a good entry
point to describe the benefits of a functional language.

------
TensorMetric
The real problem with F# is that the .NET Native UWP runtime isn't .NET
compliant, therefore doesn't allow F# code.

See this link explaining the problem
[https://news.ycombinator.com/item?id=15026396](https://news.ycombinator.com/item?id=15026396)

We wouldn't need to evangelize F#, if it just worked everywhere C# does with
proper tooling support.

~~~
toyotaboy
Barely anyone uses UWP. It's irrelevant.

~~~
TensorMetric
Nonsense, UWP is everywhere

[https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...](https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlp0muc/)

[https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many...](https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlpapbk/)

[https://www.reddit.com/r/programming/comments/6tdqmv/after_s...](https://www.reddit.com/r/programming/comments/6tdqmv/after_so_many_years_still_no_net_native_nor/dlk0rl6/?context=3)

------
DeepRote
I've experienced sort of a diagonal problem to this.

F# is way too entwined with .NET to be immediately useful to programmers
familiar with Ocaml or Scala or Haskell, etc.

Some of the basic List. _, Array._ stuff is simple enough, but then you start
talking about interfaces and classes and members and all this stuff that
doesn't really translate from C#->sanity very well.

I know people love it, but I've long considered C#/Java to be kludge languages
on platforms they don't deserve. The JVM might be the most impressive software
engineering marvel I can think of, and yet on top of that christmas tree
stands a tall, stinky shit.

I'd love to see F# as a F#-first platform, and offer .NET interop as a
secondary language feature.

I've also noticed a concerning trend in F# circles that """diversity""" should
be celebrated. There is no merit in your skin color or your genitals. If you
can hack well, you deserve to do so. End of story.

A counterpoint to the F# being poisoned by .NET is Clojure. Look how well
Clojure did Java interop and how "not a big deal it is." Immutability
everywhere, functional by default, and it feels painful to do things the Java
way in Clojure. F# doesn't mind at all if you sink to .NET trickery and in
some cases require it.

I could think of more, but off the top of my head, the .split instance method
comes to mind. I have a Markov Chain kata that I spring on new hires to see
how they do things, and .split is an instance method, which is counter-
intuitive to how functional problems are solved because you don't just |> into
it.

I'm waiting to see where Clojure goes with core.type before I abandon F#. I
really WANT to keep riding the F# train but it causes quite a few headaches.
Not more than it solves, but more than other solutions that I've considered.

To balance this out, I'll say something I really love about F#. Units of
measure. Few languages have this, and the kind of numerical work we do means
we really get our mileage out of UoM. I always see finance horror stories or
like the excel rounding bug, it makes me wonder exactly how much money UoM has
saved us from losing through some innocent type somewhere. Debugging money
code is way easier when you can verify all the conversions separately from the
logic. It feels like cheating, to be totally honest. I know there are big
shops out there that don't have UoM in their tools, and I used to feel bad for
them, but now that we have it, I can't help but NOT feel bad for them.

Anyways, yeah, F# isn't perfect. There's plenty to be said also for the amount
of progress they make with language updates. It grows a crazy amount between
major versions, and I haven't had too much problems yet taking old F#3.0 code
and revitalizing it. Very pleasant experience in that regard as well.

~~~
Boothroid
'There is no merit in your skin color or your genitals.' can't disagree with
that.

~~~
miceeatnicerice
But there's dismerit in monocultures - maybe those F# folks are pleased to be
avoiding that.

Plus, if you're situated in a historical process (like we all are) then
arbitrary things become important. Accidental weaknesses such as being perched
on the CLR and tethered to the hopes, dreams and capabilities of common-garden
C# enterprise developers invert strangely into advantages - in the case of F#,
it makes for a very friendly, welcoming ecosystem.

------
hprotagonist
404

~~~
CodeCube
maybe try again? wfm

