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.
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?
That said, people have used F# for pretty much everything - including data science and analytics, domain modelling (and business application development), testing (Canopy for web testing), build automation (check out FAKE and Paket). I guess you get the most value from F# by using it for some analytical component (implementing some logic), but the above blog post has many great ideas in other areas too.
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#.
Oh man I don't know where you are working but it sounds like you have some really good leads/architects where you are at.
I like my current job, a LOT, but it isn't a development shop and they don't want to use F# because they are trying to limit the languages they support right now (Too many legacy apps). Which I understand, but at the same time I think we are really missing out.
Especially because they are developing the front end to be a very Functional Typescrip SPA. Anyway I've been learning F# in my spare time just for the heck of it.
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.
I find F# to be really great for scripty things. Honestly, it's more of a Python replacement than C# for me.
I've scripted Google Maps scraping using F#. It doesn't showcase any particularly functional features, but you can see there is very little code (relative to C#) in order to accomplish what I needed. [0]
P/Invoke works well, too. I've called native Windows APIs to audit user-mode and kernel-mode memory usage. [1]
The last project generates a Mandelbrot image in parallel. It's as easy as `Array.Parallel.init` on line #81! [2]
F# exceeds C#'s capabilities in essentially every way. The only time C# does much better is when you need the VS drag n drop GUI tools. Some folks also feel more comfortable doing certain types of very imperative code in C#.
Other than that, sometimes there are problems with libraries that specifically target the C# compiler's exact output. Examples are functions that take an object, then dynamically look at the property names instead of just using a dictionary (F# can do this, just isn't a major focus like in C#). Or poorly written expression tree code that only works with C#'s output. That said, the F# community can often find a fix.
Once you adjust to writing so much less code, it's very hard to enjoy writing C#.
One thing though, you'll want to _really_ learn the type system and lean heavily upon it so that the compiler can guide you to build up your system.
It's the old adage of
"Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious." -- Fred Brooks
I agree a web API is a good project to start with. If anyone is thinking about trying this out, it's worth checking out Suave (worth noting that it's cross platform, works on Mac and Linux too):
I drop the .NET ecosystem long time ago. F# make me look at it, and mostly, the opportunity to use it on OSX/Linux/iOS.
I'm uninterested in C#; so I'm trying to make the case for F# (and to be more brutal: And work good enough under OSX, because all my dev work is on it; plus looking to do iOS dev with F#: That is harder than I was expecting!).
I like the language, not as much as python/pascal but is great enough. I'm toying to build a compiler, and building some utils and porting (ie: experimenting ;) ) a massive obj-c project.
So far, my only gripe, is the extremely weak support for any other database that is not Sql Server. No F# native ORM work on OSX as-is. Sql Type-providers neither. You can make some basic stuff and crash faster after you try anything barely complex, like do a search ;)
I was forced to use NServiceKit (a clone of ServiceKit before go commercial) because was the one that I made to work, but then is made in C# and it break the expectations I was having with F# (like https://stackoverflow.com/questions/31866227/why-im-getting-...)
So, that is my 5-cents: Expect pain outside VS/Sql Server, and I'm not fully convinced on the Web story neither (ie: Nothing as great + simple as django or flask on python)
> No F# native ORM work on OSX as-is. Sql Type-providers neither. You can make some basic stuff and crash faster after you try anything barely complex, like do a search ;)
There exists a very good ADO.net wrapper for F# called FsSQL
Neither are true ORM compared to say nHibernate, but both include mapping to .net collections. I generally prefer this approach over a true ORM for flexibility.
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.
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...
> Go to definition does not work across language barriers, even when the projects are in the same solution
I haven't used F#, but I do have a bunch of visual studio experience. I noticed if you do add reference to a dll (even in the same solution), go to definition doesn't work. But if you instead add a reference to a project, it does. So you might be able to just delete and re add your references and get it to work.
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.
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.
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.
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.
They aren't trying to sell you on something. It's a community run project (in fact it is a guest post not even by Microsoft themselves).
I don't think there is one magical screenshot that can sum it up. If you take 1s to scroll down you can see screenshots of each individual feature. This is just complaining for complaining's sake.
This is about community plugin for Visual Studio. You can find more on the project web site: http://fsprojects.github.io/VisualFSharpPowerTools/ Not sure this qualifies as visual, but they have lots of pictures of what the plugin can actually do :-).
If you want a visual introduction to F#, check out (shameless plug) www.fun3d.net
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.
