
Community-led tooling for F# in Visual Studio - numo16
http://blogs.msdn.com/b/dotnet/archive/2015/08/05/guest-post-visual-f-power-tools-community-led-tooling-for-f-in-visual-studio.aspx
======
smithkl42
I'm a long-time C# developer, and several years ago tried out F# for a project
for which it seemed like a reasonable fit. However, after a month or so, I
switched back to C#. I missed the very strong type inference of F# and pattern
matching, and C# suddenly seemed very verbose and awkward to me. But C#'s
tooling was just head and shoulders ahead of F#, and that made a huge
difference in my productivity. But most of what I was complaining about, it
looks like the F# community has addressed. I'll be looking for ways to go back
and play with it.

~~~
it_learnses
I'm also a long time C# developer and I would love to try out F#. what types
of projects is F# really good for? Any cool open source projects that you'd
recommend?

~~~
JackMorgan
Been using C# for a while now for shrinkwrapped winforms database application
and web site. We started intermixing F# in the last year. I've found F# to be
better than C# in everything except a few fringe cases where libraries have
done things specific to C#.

For example, F# has a better ORM framework than anything in C# with Type
Providers.... unless you need to support two databases in the same dll. Then
when trying to use nHibernate, we found that Nhibernate mappings expect
virtual properties, which F# didn't easily do. So we have a C# project with a
few C# classes used by the ORM, then a conversion layer into F# domain
objects, which we would've done anyway, because ORM classes are terrible at
expressing the domain compared to F# records and unions.

Other than a few weirdnesses like that, we've found it to be great and
otherwise a drop in replacement for C#.

~~~
it_learnses
Thanks for this :) A slightly tangential question: at what point does using
ORM become painful? When would you recommend going back to sprocs?

~~~
JackMorgan
Like when does it make sense to have a business representation of your data in
a language like F#? I'd say as soon as you want the full expressive power and
safety of records and discriminated unions. Our domain representation was
substantially different from what would easily fit in a relational database,
so we start with it from the beginning.

In C#, I think ORM classes have a lot going on, so I prefer to use them only
for converting to a data structure.

------
hravnx
I really, really like the F# language, but the tooling is so bad (compared to
C#) that it's a real struggle to continue to justify using it. I admire the
effort put in to F# Power Tools development (I've been using it for a long
time and is currently on 2.0), but TBH it's like a slow, buggy implementation
of a quarter of the C# tooling. Don't get me wrong, the effort is commendable
and I know you're not supposed to criticize OS projects unless you're involved
yourself, but from a practical day-to-day point of view, it's not working
well.

The demos that Tomas Petricek and others in the community do are nice, but in
real-world applications of even moderate complexity you almost invariably run
into impedance mismatches and annoyances.

I'm currently working on a F# backend for a service with a WebAPI 2 front-end.

\- We had to create a C# glue project to be able to publish it as a web app on
Azure. This works, but dependency tracking across language barriers in .Net is
flaky, so we have to remember to add all Nuget packages to the glue project
manually, or we get run time errors in production (not during compilation or
locally in test, but in production) as the assemblies are not published.

\- Go to definition does not work across language barriers, even when the
projects are in the same solution. So you're in F# code, place the cursor on a
data tyope defined in a c# file and press F12 to navigate to the source and
you get an F# view of the data structure, instead of going to the source.

\- The async models are famously different between F# and C#, so you have to
marshall back and forth between them, resulting in a lot of `|>
Async.StartAsTask` and `Async.AwaitTask` in the F# code, and don't get me
started on how to convert an f# async computation to a .Net Task in C#.
Pretty, it aint.

\- While you can easily create WepAPI controllers in F#, there are basic
things that you just can not do. One that bit me recently: having optional
query string parameters. Super easy in C#, impossible in F#. Ended up writing
a C# controller just for the endpoints that require this, so now I have
controllers in the same API surface written in two languages.

Neither of these things are the end of the world, but they do add up, so for
me personally it is not a given that I will use F# for my next project.

~~~
Hakeashar
Yup, it's a bit unfortunate, but that's how it is most of the time.

I found myself using F# for core libraries with clearly defined boundaries
between APIs and assemblies - IMO that's where the language shines right now.
You can have your core logic contained in a library with a separate,
C#-compatible API.

Using F# for WPF, ASP.NET MVC or ASP.NET WebAPI development wasn't quite as
stellar experience, also because of the state of the tooling. I'm even wary
about type providers, when they work - it's great, when they don't - you're
pretty much screwed with no real recourse. In case of relational DB access,
most .NET libraries (both full-ORMs and micro-ORMs) are C#-oriented.

Therefore, after including all the annoyances you listed, it's hard to justify
anything more than 'handle core libraries in F# with C#-compatible API, do the
rest in C# - it's good enough' to the business...

------
lemming
It's great that the community is stepping up to provide this functionality,
but most of these features are things that I'm very surprised that the default
tooling from MS doesn't already provide. No rename at all? No find references?
I was led to believe that the VS tooling for F# was actually pretty good but
those two are very basic things I expect from an IDE, especially for a static
language.

~~~
MichaelGG
MS simply doesn't invest in F# tooling like they do for C#. One reason is
probably the user base, but that's a bit of a catch-22. The other likely
reason is politics/saving face.

------
ropman76
As a c# dev I started to learn F# on a whim. Now I find myself being sucked
down the F# rabbit hole. The pattern matching was mind blowing. To any fellow
c# or VB devs learning F# is worth the time invested.

------
salimmadjd
I'm probably the minority here, as I'm a visual thinker. But when I see
"Visual" in the headline and click on it. The first thing I want to see is
something visual (I understand it's a product name). But on this post,
everything above the fold is just text which I don't want to read.

I'm actually very curious about F# and anything functional these days,
however, aesthetically was turned off for some reason.

Show me your best feature upfront and then I'll want to read more.

update: Looks like the moderator or the OP changed the headline to something
more appropriate. So my comment is less relevant now.

~~~
cbd1984
So far as I know, nothing under the Microsoft "Visual" brand name has ever
supported visual programming as such; it's all always been text-based source
and other normal IDE stuff. The most visual part would probably be the drop-
down menus you get with tab-completion in the editor.

~~~
UK-AL
References the visual GUI editors

