
Get Started with F# as a C# developer - edgyswingset
https://blogs.msdn.microsoft.com/dotnet/2017/07/24/get-started-with-f-as-a-c-developer/
======
GiorgioG
I'll take MS's commitment to F# seriously when they stop treating it like a
2nd class citizen. .NET Core 1.0 has been out for over a year, .NET Core 2.0
is in preview and there is ZERO support for F# with .NET Core in Visual Studio
2017. Yes you can use VSCode, but VSCode is no Visual Studio - it's a text
editor on steroids, not a proper IDE that most C# developers have come to
expect.

~~~
louthy
I agree, it's been a nightmare. I've dropped support for F# from my FOSS
project because I can't get the .NET Core build working alongside the C#
projects (and packed in a nu-get package, and deployed all in one process). I
know that if I try to use it alongside any C# projects I will almost certainly
lose many hours of time and it probably will fail to work at all.

I don't know how much of this is the F# team's fault, but F# the 'eco-system'
feels like it's going backwards at the moment.

~~~
kirse
_F# the 'eco-system' feels like it's going backwards at the moment._

As in physics, it's all relative. .NET has been moving so quickly lately that
the F# team (from my outside-looking-in view) does not have the resources to
keep up. You can see that by how stretched thin they are on GitHub issues. I'd
imagine things will eventually stabilize once .NET Core settles in, but
that'll be a few years.

But you are right, the tradeoff always seems to be "do I want to struggle and
learn" or "do I just want to get things done."

~~~
GiorgioG
If you want to get things done in .NET Core, use C#. If you want to learn
functional programming then sure, use F# and the full .NET Framework...but
good luck finding help when you need it because compared to the number of
people Elixir, Scala, etc - hardly anyone is using F#.

I started learning F#, but ultimately I decided I'd rather learn either Scala
or Elixir because they are more "mainstream" functional programming options.
If anyone doubts this, compare the number of F# repos to Elixir/Scala on
Github.

I've voiced my frustration on several Github issues about the fact that F# is
understaffed at MS, that F# is a 2nd class citizen to C#, etc - to no avail.
It's fine, management at MS makes those calls...but then they shouldn't be
surprised that there's no uptake on F#'s usage.

~~~
wyoung2
> If you want to get things done in .NET Core, use C#.

And if you want to get things done in F#, don't use .NET Core. :) Good thing
.NET Core is merely the .NET du jour, not the only .NET.

> If anyone doubts this, compare the number of F# repos to Elixir/Scala on
> Github.

Challenge accepted. It turns out that GitHub's advanced search page can answer
questions like this directly:

Projects written in F#: 4,246
([https://github.com/search?utf8=%E2%9C%93&q=language%3AF%23&t...](https://github.com/search?utf8=%E2%9C%93&q=language%3AF%23&type=Repositories))

Projects written in Elixir: 4,667
([https://github.com/search?utf8=%E2%9C%93&q=language%3AElixir...](https://github.com/search?utf8=%E2%9C%93&q=language%3AElixir&type=Repositories&ref=advsearch&l=Elixir&l=))

That's less than 10% higher. Plus, I'd guess there is a bias against closed-
source projects in that result, owing to the nature of .NET.

Scala is indeed a lot higher at 38,424 projects, though I wonder how many of
the complaints about F# from C# users apply apply equally to Scala. (e.g. Poor
GUI builder support, no native compiler, etc.)

F#'s language representation on GitHub is also nearly equal to that of OCaml,
a much older language.

I'd say that's a pretty good showing for a new-ish language. Not everything's
going to pop to the top like Swift, which IMHO is a "people in Hell want ice
water" reaction to Objectionable C.

~~~
GiorgioG
> And if you want to get things done in F#, don't use .NET Core. :)

Yep - stick with the version of .NET that MS is desperately trying to
deprecate - remember recently when they tried to get away with not supporting
ASP.NET Core 2.0 on the full framework?

> Good thing .NET Core is merely the .NET du jour, not the only .NET.

Yep, who would want to use the cross-platform, modern implementation of .NET?

> That's less than 10% higher.

Except that F# has been around twice as long as Elixir (2005 vs 2011.)

F# is the minor league team that C# farms features from. Nothing more in
microsoft’s eyes.

------
nlawalker
Can anyone suggest any F# tutorials in the style of Michael Hartl's Rails
Tutorial?

F# suffers from an overabundance of "getting started" tutorials that focus
only on the language and syntax. I get that F# is likely to be a lot of
peoples' first introduction to a functional language, so that makes sense, but
this one doesn't even tell you how to run the code it's showing you.

The hardest part about learning any new language isn't learning the syntax or
core concepts, it's understanding the mechanics of actually getting things
done - grokking the developer workflow, getting comfortable in an editing
environment, building and deploying, troubleshooting and debugging, writing
idiomatic code, learning about common libraries and tools, etc.

~~~
matteuan
I think there is nothing better than the book: Expert F#
[https://www.amazon.de/Expert-F-4-0-Don-
Syme/dp/1484207416/re...](https://www.amazon.de/Expert-F-4-0-Don-
Syme/dp/1484207416/ref=sr_1_1?ie=UTF8&qid=1501264192&sr=8-1&keywords=expert+f%23)

~~~
nlawalker
I'm making my way through it now, but it doesn't have quite what I'm looking
for.

I just found
[http://fsprojects.github.io/ProjectScaffold/structure.html](http://fsprojects.github.io/ProjectScaffold/structure.html),
which is a good example of the kind of thing I'm interested in
(ProjectScaffold in general, but that page in particular, which actually
explains what everything in the project structure is for).

------
hdhzy
Are there any simple projects like HTTP server in F# for CoreCLR somewhere?
With a Dockerfile if possible. Last time I tried to build something like that
for PoC the amount of struggles I had with various versions of CoreCLR was
overwhelming.

~~~
kirse
Giraffe is a fantastic little project that is a thin layer on top of ASP.NET
Core. Works out of the box with the provided template, test locally, deploy to
Azure, etc.

[https://github.com/dustinmoris/Giraffe](https://github.com/dustinmoris/Giraffe)

~~~
hdhzy
Thanks but I'm looking for something simple like returning plain text in 200
HTTP response using only built-in API. Completely _minimal_ example. Using
framework for me now would be like learning JavaScript by writing SPA in
React.

~~~
kirse
FSSnip usually has those things. If you're talking _that_ minimal I would just
look up existing C# docs and translate them over to F#... ASP.NET Core is very
lightweight w/ Kestrel though.

[1] [http://fssnip.net/7OR/title/Simple-HTTP-
Server](http://fssnip.net/7OR/title/Simple-HTTP-Server) [2]
[http://fssnip.net/search/http%20server](http://fssnip.net/search/http%20server)

~~~
hdhzy
Wow, that's exactly what I wanted. Thank you _very_ much! Fssnip looks great.

------
NicoJuicy
If you want to try out f#, don't forget to try it with
[http://fsharp.github.io/FSharp.Data/](http://fsharp.github.io/FSharp.Data/)

It's pretty awesome

------
stinos
Ask HN: I've toyed around with F# and I kinda like it but I've never dug deep
enough into it to answer the question: can I use this for 'real life' code as
part of an existing C# desktop application for instance, e.g. build some F#
into an assembly which is callable from C#? Without tons of hassle? What are
good samples of real life application code in F#?

~~~
eurg
> Without tons of hassle?

Well, yes and no. You definitely can do this, and for some applications it's
worth it, but often the overhead at the API level will make you cringe.

APIs designed for C# are very different than APIs designed for F#, to account
for partial application of functions, sum-types, non-nullability, immutability
and value-like behavior by default from F# types, and also to make good use of
F#'s type inference. Also, given stuff like the |> operator, making "fluent"
APIs looks very different.

Using APIs made explictly for F# from the side of C# is somewhere between
enormously annoying and de-facto impossible. The other way 'round, it's just
massively annoying, as you lose many advantages of F#, and the code will not
be much more compact as if you would write it from C#.

Pain-points in practice are around F# functions vs. C# methods and delegates,
async/await vs. async-expressions, code quotations vs. Linq expressions, etc.

To be productive in F#, you want your API small and primitive, and stay within
the language for the rest. If this is possible, go for it; if not, evaluate.

A final tip: Porting a big block from C# to F# is much less work than it
sounds, and opens the door to refactoring that part into something sensible.

~~~
maxxxxx
Are there any F# APIs? I tried to introduce F# to a project but between all
needed APIs written in C#/OOP style and only mild interest from a lot of
developers and managers I couldn't really justify the added friction.

If there were a ton of F# libraries that showed how to create functional APIs
people could learn from them by using them the same way a lot people learn OOP
by using APIs.

As it is now the only way to get into F# is to have a group who really wants
to do it and learn. Otherwise it's just an uphill battle.

------
debacle
I need to know _why_ to use F#, not how. C# is a business programming
language. F# doesn't appear to be obviously useful in that regard.

~~~
steego
I would argue that F# is a better business programming language for a lot of
reasons.

First, the type system is great when it comes to modeling the problem and
communicating that model with non-technical project managers because writing
good data models often means you write clear code that's idiosyncratic to the
language. My experience is non-technical people understand clear data models
and pipelines and those are two areas where F# code reads very clearly.

If OOP is your thing, I can argue it's a much better OOP language than C#.
From a SOLID and Design Patterns perspective, the language has been
streamlined to encourage a good OOP style by default. Design Patterns are
simpler (Factory, Builder, Decorator, Adaptor, etc). Dependency Injection is
very natural and implementing fluent APIs is a lot simpler.

The biggest benefits come from maintaining good hygiene. You're a lot less
likely to have null reference exceptions or introduce invalid states. Race
conditions are harder when most things are immutable by default. You're also
less likely to encode things poorly because your type system sucks. You'll
think more carefully about how you write loops, ifs and switch statements
because the compiler catches and prevents you from doing boneheaded things.
It's also has features that prevent you from accidentally adding cyclomatic
complexity. For example, lower-level modules are not allowed to refer to
higher-level modules. It's also harder to accidentally make functions
recursive because it requires a special "rec" keyword.

I realize people dismiss hygiene, but this stuff really goes a long way to
help manage complexity when it comes to growing and maintaining applications
over long periods of time.

I'm not going to claim it's great at everything. It's a wonderful back-end and
business language, and it's fantastic at modeling business objects and
records. However, the tooling isn't there for doing WPF applications. Also,
sometimes you come across issues with libraries that work well with C#
defaults but not F# defaults. For example, F# properties tend to be read-only
by default, so libraries that hydrate objects with data don't work unless you
explicitly make those properties writable.

Nevertheless, if nothing else was an issue (buy in, training, etc), I'd opt to
write the business logic in F# 9 times out of 10 times and save C# for the
front-end (tooling).

~~~
nlawalker
_> > the language has been streamlined to encourage a good OOP style by
default. Design Patterns are simpler (Factory, Builder, Decorator, Adaptor,
etc). Dependency Injection is very natural and implementing fluent APIs is a
lot simpler._

Can you expand on this? I'm interested in how these things are easier in F#
than in C#.

------
oxryly1
Asynchronous programming with F# is pretty cool. It has layered powerful
syntax and language constructs on top of .NET's threads and tasks, AND it
gives you convenient access to the same async API that you use in C#.

~~~
jackmott
performance is not good though, if you are trying to use it to leverage
multiple cores.

~~~
oxryly1
Is this because of GC? I just came across this statement on the Hopac site:

> Before you begin using Hopac, make sure that you have configured your F#
> interactive and your application to use server garbage collection. By
> default, .Net uses single-threaded workstation garbage collection, which
> makes it impossible for parallel programs to scale.

------
marvel_boy
Newbie here. Somebody can point to useful other resources for F#?

~~~
kzisme
Is there a really good reason to choose to use F# over C#? Or does it really
just come down to preference?

~~~
sremani
The returns on choosing F# are very much reliant of level of proficiency
attained.

Once you are proficient, you will write

\- less code for similar functionality

\- have lot less dependency cycles

\- using Option types over null helps in the long run

\- improvement in productivity

The only problem is that you have attain a level of proficiency and flip the
"train" of thought from OOP to Functional, and that can take some good time.

~~~
kzisme
Gotcha - thanks! I haven't touched functional languages other than for fun
lately, so I may take a look sooner or later. I've always been interested.

------
nullspace

      // Flip the BST using pattern matching!
      let rec flip bst =
        match bst with
        | Empty -> bst
        | Node(item, left, right) -> Node(item, flip right, flip left)
    
    

Without type annotations, how can it tell the flip takes an instance of BST as
the parameter?

~~~
omaranto
The variable bst is something that can be matched with Empty and with
Node(item, left, right), both of which are of type BST. When two values can be
matched with each other, they must be of the same type. Therefore bst is of
type BST too.

