For those of you out there who are using f#, what areas of functionality are you coding with it? What is the language really well suited to and what does it do with far more power and ease than say c#?
15 Answers
Deep Fried Bytes #24 podcast covered this:
- Algorithmic processing (including calculations)
- DSL creation
- Concurrent processing (immutable data, message queuing, asynchronous workflows)
And of course, for many systems F# may form a processing core, but it seems to me that it will more often than not be wrapped (interface, user or otherwise) with C#/VB to provide a conventional interface.

- 106,783
- 21
- 203
- 265
I'm currently using F# to develop my next indie video game. So far I'm finding that my normal OO approach is different from how I develop in c#.
Some good things I've noticed is that I'm using smaller functions on average ie the number of lines per function is way down. It's also more natural now for me to scope a static private member function to be inside of another member instead of having it be exposed to everything in the object. Writing a collision algorithm was really easy. It's a bit early for me to say that writing algorithms in F# is easier but I'm already leaning that way.
Not everything has been roses since I started using F#. I'm still finding online documentation lacking. Expert F# has been of some help but since it skims over OO it leaves me lost a lot of times. It gets on my nerves that the author chose not to go very deep into OO when it's currently the most popular form of development. I'm not looking to dump OO. I'm looking to integrate functional into it.
The biggest advantage I've seen so far has been my codes correctness. I know it sounds funny but every time I've gotten my code to compile, it has worked as expected. I hope this is still the case when I break the ten thousand lines of code mark.

- 13,732
- 5
- 36
- 69
-
1I've also found F# to be painfully lacking in documentation in general. – Paul Nathan Feb 20 '09 at 20:32
-
2While far from complete, i've found http://en.wikibooks.org/wiki/F_Sharp_Programming to be a good fast reference. – Rick Minerich Feb 20 '09 at 21:38
-
1OOP being popular != OOP being the best. F#'s functional power is exceeding of it's OOP power. I wish they would have just left OOP out of it, because as long as it's there people will ride on it. :| – Rayne Feb 26 '09 at 19:55
-
F# documentation here: http://stackoverflow.com/questions/tagged/f%23 (smile) – Benjol Oct 29 '09 at 15:08
-
1fast-forward to 2010, now MSDN has **excellent** documentation on F# : http://msdn.microsoft.com/en-us/library/dd233154.aspx – Mauricio Scheffer Apr 23 '10 at 15:51
- Scientific works (Mathematical and statistical calculations, visualization, optimization,..)
- Parallel programming (F# supports asynchronous workflows, Erlang style concurrency, Parallel FX, ...)
- Language oriented programming (eg. DSLs)
- Data intensive analysis
- ...

- 2,111
- 3
- 17
- 18
I currently explore the uses of F# in
- SOA
- Parallel execution
- Data Intensive
- Long running processes

- 6,599
- 12
- 50
- 69
-
-
Learning F# helps me understand the new features found in C#, it also allows me to explore new ways of looking at problems and at new possible solutions. – Alexandre Brisebois Mar 26 '09 at 11:16
Small(ish) data processing scripts. Think parsing long log files and trying to detect "strange" behavior. Active patterns and stream processing make for nice (and fast) programs. I used to write these in C# but they were throw-away - using F# I actually find myself reusing previous scripts and extending them.
Testing using FsCheck (well ok, I guess that's cheating as I ported the thing myself...), but it's been amazingly useful (I was actually surprised at this myself ;) ) not only for testing F# programs, but .NET libraries in general. Since FsCheck is a testing DSL, I guess I should join the DSL bandwagon as well.
I've been wanting to use F# with WPF or XNA for ages now, but haven't gotten round to it.
Contrary to some I've found that once you get the hang of F#'s implicit class construction syntax, OO programming using F# is just as enjoyable, if not more than using C# or VB.
It is true that if you write a library in F#, unless you're very careful it ends up being interoperable only in theory. Truly interoperable F# libraries either need to be very careful what F# constructs to use, or write a C#/VB wrapper.
Kurt

- 8,880
- 1
- 30
- 48
F# does pretty much everything C#, only easier. It's advanced features mean you end up writing a lot less code. OO syntax is more verbose than the other F# syntax, but it's still better than using C#.
We're using it for web services, ASP.NET MVC sites, daemons,
The question is, where not to use it. Right now that looks to be mainly where tool support is lacking. So, for example, with ASP.NET, the ASPX page inline code is C#, but the controllers and everything else is in F#.
The few places where F# isn't as smooth as it should be I imagine will be worked out in the upcoming releases.

- 9,976
- 1
- 39
- 82
Here are some good practical uses of F# and Functional programming from Trauma Pony given as an answer to my similar question.
- Computational fluid dynamics
- Physics processing
- Ray tracing
- Data mining
- Medical imaging
- Control engineering software
- Digital signal processing
- Bioinformatics
In fact, check out this page for a lot more examples of where GPGPU has been used.

- 1
- 1

- 33,810
- 26
- 104
- 151
I'm considering using F# for HTML processing because the list pattern-matching syntax fits the problem domain well (Prolog is probably better, but still).

- 23,067
- 22
- 97
- 166
1) Simulations (Ants and Mycelium)
It's easy to leverage async workflows to make for massively parallel simulations.
2) Unit Tests for C# API
F# makes for short, sweet and very readable tests. Also, FsStory is quite nice.
3) Data Analysis and Visualization
It has great visualization libraries and it's very fast to try different things out. I also love VSLab and hope it sees another release soon.
4) Rapid XNA Development
Once you have a small framework set up to keep the object-orientedness of XNA at bay, F# development is much faster and also much easier to experiment with.
In short, I find F# to be fantastic anywhere development speed or immutability trumps API correctness. If there was a pragma or compiler flag to turn off type inference for public functions and type definitions, I'd probably be pushing to use it for my APIs as well.

- 3,078
- 19
- 29
I'm using quotations, linq expression compilation, dsls, async workflows, and the typical fp constructs for a client at the moment. Lots of interop with C#.
I'm using F# to develop an engine for a turn-based strategy game I'm playing with designing. I've found that F#'s mix of functional and OO programing has let me manipulate the data in the game concisely in ways that would be too complicated in an imperative C# to want to do. It's also pretty natural to separate the state-changing actions from the folds and such that determine how the state should change, which definitely helps keep the code simpler and organized.
The biggest trap I may be falling into in the project is using type annotations of tuples for a couple of data types that are used quite intensively in one of the classes. Using tuples makes for pretty concise code, but I'm not sure that using the type annotation in the signature of the functions that use them is sufficient to maintain readable code in some cases.
I am using F# for receiving(TCP), parsing and storing binary protocol messages from industrial devices. Currently, I'm testing async workflows.
Next project is visualization and analysis of received data.

- 13,384
- 14
- 59
- 75