
Why Isn’t F# the King of .NET? - douche
https://medium.com/@chrisdaviesgeek/why-isnt-f-the-king-of-net-2a9a1963e087#.edqv5al5j
======
pjmlp
Several reasons come to mind:

\- F# replaced C++ on the black sheep role from Microsoft languages list,
usually missing from their documentation when they list available languages
(.NET Native and .NET Core are two examples)

\- Lack of GUI tooling forcing any desktop developer to use a mix of C#,
VB.NET, C++/CX for the UI + F#, or load XAML files by hand via type providers

\- It is easier to gain adaptation at the enterprise level with multi-paradigm
languages and existing ones are getting good enough support for FP algorithms,
even if it is not clean approach. I rather have this than no FP at all.

\- Many enterprise developers and their managers are still quite vocal against
type inference and LINQ in C#, VB.NET, let alone allow something like F# on
their codebases

\- Since F# got type providers, many presentations try to sell the language to
C# devs based just on this feature, which doesn't matter at all for the
typical ETL and CRUD enterprise applications

~~~
youdontknowtho
They actually explicitly used to say...do your UI in VB or C# and your compute
intensive work in F#. F# just wasn't their focus. They were productivity
language/tooling focused.

I haven't heard anyone against type inference. Not saying that it doesn't
happen. Every place has it's weird "thing"...just haven't seen it personally.

I guess I'm saying that I don't think it was some kind of conspiracy or
anything. I just think that there focus was/is elsewhere.

~~~
pjmlp
> I haven't heard anyone against type inference.

I have seen C# style guides that forbid _var_.

~~~
douche
I've worked with people that couldn't be convinced that using var in C# was
not the same as the old terrible untyped Variant type from VB.

~~~
nathanaldensr
var is _not_ the same as Variant. var is merely a placeholder for the real
type, which the compiler infers from the RHS expression type. Variant is
closer to object than var.

EDIT: It turns out the parent and I agree 100%. Darn double negatives! :)

~~~
masklinn
Isn't that exactly what GP is saying?

------
jbb555
Because it's a functional language. And other than noisy functional language
fans, most people prefer imperative programming.

~~~
dasmoth
I'm not entirely sure why this is getting downvoted. I'm a moderately noisy FP
fan myself, but this statement does seem, on the balance of evidence, to be
true. I'm interested to know _why_.

~~~
V-2
Maybe because dismissing those who appreciate the advantages of functional
programming as "noisy fans" is condescending, and implies that their
preferences are based on emotional rather than rational grounds. I'm not a
noisy fan of FP at all, but I like a lot of concepts (like immutability), and
I do adapt them in my code

~~~
richardwhiuk
I think noisy fan was meant to imply that people who are in favour of
functional programming languages tend to be more vocal in their views, rather
than those who are in favour of imperative programming languages.

This is probably because imperative languages are the majority, so there's no
need to soapbox, rather than anything related to the communities or the merits
involved.

~~~
V-2
And if the downvoted comment used the phrase "more vocal in one's views"
instead probably it wouldn't get downvoted much

------
skrebbel
I think it's syntax.

C# was _painstakingly_ designed to be palatable by large hoards of
programmers, most of which used C++ and Java at the time. With stuff like out
and ref parameters, the unsafe keyword, a C++-like class syntax (even with
things that look like destructors), it was obviously an important goal to
appeal to C++ programmers more than Java could.

F#, on the other hand, doesn't look familiar at all to anybody but experienced
functional programmers. This matters, because as a language you don't get a
lot of time to seduce programmers. Most of us use the first code snippet we
see as a way to determine whether to keep reading or close the tab.

That, or the language really needs to offer something special to keep us
reading. PHP's advantage was "just upload some files over FTP and it works, no
need to learn that complicated unixy cgi-bin stuff". Elixir/Erlang/go have
"super high concurrency without the headaches". None of F#'s many cool
features have the same "ok, now you got my attention, I need this, _now_ "
aspect.

These days there's a wider variety of syntaxes that a common. Ruby, JavaScript
and Python became popular, also more popular than they were when F# first
appeared. I suspect the syntax will feel less strange to many people. Maybe
things are going to change.

------
thr0waway1239
As someone who keeps hearing about F# but has not used it, I look at C#'s
evolution - generally speaking, the language just keeps getting more and more
terse for the common use cases (without sacrificing readability), especially
in line of business applications. Combine it with a tool like Resharper, and
generally, coding in C# is quite a pleasure.

Also, it is not as if C# is stagnant - e.g. the introduction of async and
await keywords.

It _seems_ as if people promoting F# try to create use cases which are,
frankly, not very often seen in the domains where C# is commonly used. Maybe I
am completely mistaken, but F# seems to lack a so called "killer app" use case
where people notice and say "aha! That's why you need it".

~~~
dgudkov
As someone who writes in C# and F# I can say the absence of nulls in F# alone
makes it worth switching. Typically if something compiles in F# then it works
reliably - a huge time/money saver.

~~~
thr0waway1239
Not disagreeing - can you explain a scenario where this helped so we can all
understand how it is better than dealing with nulls in C#?

~~~
DontGiveTwoFlux
I'm working on a big c# app right now. All over the code base are areas where
we always assumed a call to .first() would always return at least one thing.
The business needs have changed and now we have use cases where we return
nothing. I've been playing a game of hunting down the many little areas where
this could crop up.

I can imagine that in f# this refactor would be a lot simpler and would allow
me to have a case of empty that I could propagate around and handle
transparently.

~~~
sickbeard
How would functional programming help you in this department?

~~~
piaste
In C#, null is just one possible value of the regular type Foo. The compiler
cannot tell whether you have started returning null where you previously only
returned non-null values, nor can it tell whether you've handled those null
values correctly at the consumption site.

In F#, None is a subtype of the Option<Foo> union type, which is different
from the plain Foo type and from the other subtype Some Foo. If you change a
function that used to return a plain Foo into one returning Option<Foo>, every
place in your code where that function is consumed will throw a compile error
until you edit it to unwrap and handle the distinct Some Foo and None
subtypes.

------
d33
The title would be better as "Why the F# Isn't F# the King of .NET" ;)

------
koder2016
Some of reasons reasons:

1) F# team prefers an ivory tower of pure language design to making killer
_new_ products like Akka.

2) Meaningful whitespace is a matter of taste and not some golden standard. I
like my languages with punctuation marks in them, thanks very much.

3) Total global inference and ultimate succinctness is a matter of taste and
not some achievement. I don't program in Brainfuck and ML.

------
xyzzy4
_> I think within five years or so, functional-first programming will be the
norm. _

I highly, highly doubt this.

~~~
youdontknowtho
The guy that writes Mechanical Sympathy, Martin Thompson, has said that people
who think pure functional programming are the future are missing the point
that hardware favors the imperative model. He's worth a listen to. Many talks
on YouTube.

~~~
Pica_soO
Im hearing that for the first time, could you elaborate?

~~~
pjmlp
The issue is that imperative algorithms and data structures are easier to
optimize for hardware regarding cache sizes, memory access patterns and memory
reuse.

Whereas this is also possible in FP languages, but since they tend to abstract
the hardware, it requires support from "clever" compilers.

I don't fully agree with him, given the previous experience with the
Connection Machine and *Lisp, but as usual in computing, unless one doesn't
implement something and prove it with benchmarks, it doesn't happen.

[https://en.wikipedia.org/wiki/Connection_Machine](https://en.wikipedia.org/wiki/Connection_Machine)

~~~
youdontknowtho
Actually, that was one of his major points in the lecture that I referenced.
Basically, you should start with measurements and go from there. He said that
he personally uses FP quite a bit, so he wasn't a hater per se...except for FP
fan boys. He did go on about that quite a bit.

The main thing that he stressed about data structures was that memory layout
matters in that hardware has a lot of built in intelligence for accelerating
memory access patterns that it can discern. The way that immutable data
structures are created, updated, and destroyed don't produce a suitably
detectable memory access pattern, apparently. His explanation was detailed and
is worth watching. That being said he wasn't proposing "share state for all".
He was mainly proposing the scientific method.

------
mhomde
I actually think it's catch-22 with popularity as well as being a bit niché.

* When choosing language/platform for enterprise projects (where .Net is most commonly used) the company will go with one where they can find/have talent and resources. There's not many F# developers out there so you're severely limiting yourself.

* Since C# is more popular and has better tooling there has to be a substantial advantage of using F# instead. From what I can see that may only happen in certain financial and engineering solutions where minimizing the risk of errors, unit conversions, calculations etc is severe (Lose a couple of million dollars/Challenger-explosion -severe). Those projects are pretty far between ,and in some of them you can simply make do with c#. Another problem might some of those kinda of projects are usually not done in .Net to begin with.

It seems that F# is very nice for projects that are more based around
calculations and formulas, but that's not enough for it to gain critical mass.
Also C# has been encroaching on F# by becoming more functional with things
like LINQ, lambdas etc. The type system is worse (C# main weakness right now),
but still.

I'm no F# expert though so feel free to correct me

~~~
iopq
I would totally learn F# if I got hired for a job using F#. C# not so much. I
wouldn't even apply to a job if it was a Java development job.

------
lobut
I tried playing around with it for a little while. I had trouble dealing with
functional in the .NET world. That's purely on me. However, I tried writing a
WPF app and the scaffolding required was a bit absurd. Then I tried writing a
web service. A LOT less scaffolding and I did get me off the ground a bit.

However, trying to apply some existing things were slightly confusing. I had
trouble understanding immutability with the existing C# structures and wasn't
sure if anything I was doing in this was correct. My Google-Fu was a bit weak.

What I found strange was that I wasn't able to create a Folder in Visual
Studio. I'm not sure if that was a design choice, but I decided that if
Microsoft wasn't going to take this language seriously. Then I wouldn't
either.

------
debacle
One thing I don't see mentioned - C# allows you to write pretty functional
stuff. The Action and Func objects allow me to do a lot of what I would
normally want a true FP language to offer, and most of the rest can be
accomplished by convention.

------
mamcx
I like F# much (and hate any C-like language as the plague!) but let's not
mislead ourselves. F# have inferior tooling, is worse for database
development, type inference is crazy sometimes and is hard to build the same
kind of generic solution as with C# or similar languages.

I use it only on osx and is even less good. Still stick with it because I see
the potential and the time-savings in other aspects, but after years on OOP-
Imperative have take a long time to get there...

------
Melchizedek
"It has killer tooling — some of the best in the business "

Some important things are missing compared to C#. I can't use F# in the
immediate window in Visual Studio, so if I set a breakpoint I have to use C#
to interact with the program, which is extremely weird and impractical.

F# is a _fantastic_ language though.

------
zerr
It would have been if C# stayed at v2.0.

~~~
brianwawok
You think? C#2 isn't far from Java, and yet Java still dominates over Scala.

------
cgtyoder
Yet another "my programming language is better than your programming language"
blog post - have we really not progressed beyond this?

------
Yuioup
Just curious. What "flabby messaging system" is the author referring to in the
article?

~~~
mamp
I think he is referring to BizTalk.

------
coldtea
Because marginal returns...

The author alludes so too: "C# is good enough for most".

------
_nalply
First I read «Why isn't it the Fucking Kind of .NET?». Go ahead and downvote
me :P

