Ask HN: What do you think of F#?

I had no idea what it was. For those similarly unaware: http://research.microsoft.com/en-us/um/cambridge/projects/fs...

I just don't see a big enough advantage compared to its parent, Ocaml. Partly because I wouldn't count Visual Studio and .net on the "pro" side. Ocaml is basically the same language, you don't have a big methodology mismatch when using libraries, it produces smaller executables that are quite fast, its runtime has some advantages if I remember correctly. (And there's the evangelist problem, but let's not get into that again.)

   - ability to create a structure isomorphic to GADTS
   - further enhancements to metaprogramming and how it does quasi quotation stuff
   - Support for Higher Kinds

I love it. The classic problem of the niche languages, in this case the ML family, has always been the lack of commercially relevant libraries. Which is understandable, the strongholds of OCaml, Haskell, ML etc have traditionally been academia. The other problem is that organizations have been reluctant to start projects in languages for which it has been, rightly or wrongly, perceived that there is poor liquidity in the job market, regardless of the inherent advantages of those languages.

Both those problems have been solved in one fell swoop. Not only is the entire .NET ecosystem available, but it's a shipping, fully supported part of Visual Studio 2010. There is no reason not to use it, from the organization's perspective. Finally, all the FP programmers who've been hiding in the closet, hacking in Haskell on their personal projects, can come out! These are great days!

I've used it for some pet projects, mostly to get my head around a functional language with an easy entry (and exit) route for me: I'm a C# guy by day.

I started doing the Euler things etc. and did a quick dive into lexing/parsing (one strong point that your list is missing, imo). I got hooked. While I still cannot use F# for most of my things (technically it would even be possible, but try to convince your higher-ups that it is a good idea to switch to a language that they've never heard about, "because it is fun"), I use it for small things on a regular basis. You can mix functional and structural/iterative style (which is a plus in my book, the latter just _is_ faster if your program really wants to lend itself to mutable loops in places). You have a huge and well-tested library - the interaction with everything .Net is trivial.

Deployment isn't a big issue anymore: In the past you needed to either compile it statically or ship the F# stuff as well, with its status as a "first class citizen" in .Net 4 there's really no reason to back away from it anymore. It's here to stay.

I didn't have any trouble running it on mono/linux - but I've to admit that I last tried it quite a while ago.

Full Disclosure: I'm a kind of a fanboy here, I guess. The wall in my back is painted with a very nice/succinct 13 line prime number generator in F#, roughly 4cm line height, done as a decoration by my so.. ;)

I used it in a computational finance class about a year ago. I develop solely on Linux, and although it was painful to get working, it definitely wasn't the worst thing I have had to do on Linux...

The actual language was weird. Apparently it was inspired by OCaml, but I felt it was far more verbose 90% of the time, and then randomly succinct. F#'s error messages were straight up useless.

If you are looking for a good functional language, I would probably look elsewhere, but it does have the advantage that it is currently still being worked on, and it has all of the benefits that the CLR brings.

At the very least, I agree with the other comment that it will probably bring more people into functional programming, which is always a good thing.

From what I have seen, it seems that MS is pushing this as a way to parallelize a section of your application. Meaning that you would use c# for most of the app and write a performance critical/parallel section in F# to avoid using locks/ critical sections.

Maybe I'm seeing things wrong, but it seems that MS is not looking to make F# as mainstream as c#.

This is a bit of an off-topic rant, so feel free to skip it if you would prefer a direct answer to the question.

For many years I've made it a point to studiously ignore languages that come out of Microsoft, having been burned too many times by their constantly shifting and sometimes suddenly-expensive tools. Before anyone mentions price, sometimes the expense is hidden in places like what system I would have to run, with what total cost of ownership, in order to use their stuff. There may have been some unknown opportunity costs to me, but I am blissfully unaware of these and have had plenty of other fun languages to use.

I've been enjoying using it for both some personal and commercial projects. Points I've noted myself that aren't really discussed so much in the usual analysis, or maybe they're the 'small print':

1. Active Patterns are incredibly useful. Active Patterns are the f# equivalent of 'View Patterns' in Haskell. In other words they allow you write a function that converts something into a pattern matchable form. The first example I saw of this in Haskell was the ability to write a function of the form:

dec (n + 1) = n

which performs the same function as:

dec n = n - 1

Whilst that 'cool' I didn't really see the applicability. Now you're in the f# world and trying to interact with .net libraries its suddenly amazingly powerful! Suppose you have a DOM api or something like that, that the idiomatic functional approach would involve heavy pattern matching. Hey presto - one simple function and you've wrapped up an imperative .net library and you can think of it like a discriminated union.

2. Multiple collections libraries are annoying. There's some functionally oriented stuff in the f# libraries, but sometimes its a pain to get it to interact with existing c# code - you might need to do some conversions. The Seq module works over sequences - which are instances of IEnumerable - but you find yourself looking at the LINQ extension methods, and the legacy c# functions and then the f# ones and thinking 'its one platform - why are there 4 ways of doing something?'

3. The f# compiler takes a while to generate code under Mono. I've not tried mono 2.8 yet, but as of 2.6 it takes a significant amount of time to compile projects. If you're compiling code in order to try and get a few errors, a common thing to do if you're used to using your compiler to find bugs in your code, then this becomes a bit of a productivity drag.

4. Intellisense is still useful for functional programmers. I've noted a propensity among advocates of self-described expressive languages to claim that an IDE is a crutch for weaker programmers, or perhaps produce some other ill conceived but dismissive response towards IDEs. In the past I've considered the notion that the support something like Eclipse or IDEA gives to Java programmers or Visual Studio gives to C# is something unnecessary in the functional world. My mind on this matter has been changed by two things - one being the Visual Studio support for f#. Its not as good as c#, but its at a pretty young stage and is already highly useful. I feel a lot more productive in visual studio than vim for example. The other aspect was my efforts in teaching beginners to program haskell about a year ago. I was expecting a lot of people to get stuck on Monads and combinators etc. What I didn't expect was them to become confused on basic programming issues - things an IDE would help them find solutions to more easily in a language like Java. So I'm inclined to think from these experiences that IDEs are useful, even in a succint language like f# and more importantly both to beginners and experts alike. (Assuming I can consider myself an expert.) There's already a tool that provides the intellisense support in an out-of-ide environment, and I hope that it will mature soon enough that I'll be able to use it within vim.

I have a few more minor points - but I think thats all of interest for now.

I've been using it regularly for over a year, and I love it. I could start out imperative and then code more and more in a functional style as I got to be a better functional programmer.

Having said that, I did find the transition painful. But that's going to be true of transitioning to FP no matter how you do it.

I'm still in a Windows environment, but I look forward to transitioning to Mono once I get FP down. At that point I'll be on an open, free stack, programming in a powerful language with tons of libraries and thousands of people to help if I have problems. What's there not to like?

At Atalasoft, we decided to make F# an allowed language for development (in addition to C/C++, C++/CLI, and C#). We make imaging toolkits for .NET. There aren't many downsides compared to C# -- it's totally interoperable with our code, can be used to implement OO interfaces quite well, and it has some nice advantages (terser syntax, inlining, asynch blocks, etc). The main downside is in dealing with anything that uses Visual Studio Design support.

We don't use it for everything, but it has its place.

I used it for a while a few years ago. Like O'Caml or Haskel , F# is a language that forces you think through your problem up front. For example you must get your types exactly right before the program compiles. In return, you get fewer runtime errors, e.g. fewer null pointer exceptions.

I stopped using it when I changed jobs and left the Windows platform.

I don't really miss F#. It was fun to learn and use, but wasn't helping me write better programs quicker than C# or Python.

Check this Ocaml talk by Yaron Minsky from Jane Street Capital: http://news.ycombinator.com/item?id=1533275

He said, that unlike Ocaml, in F# you still can get Null-pointer exceptions, since it's based on .NET

I'm curious as to what libraries are available for linear algebra and numerical computation (free / open source ones) and how they compare to e.g. Numpy, mpj or colt on java, etc?

I love it. Pair it with a few C# projects to get all the LINQ-TO-SQL goodness and ASP.NET MVC + nhaml and you've got yourself a beautiful way to develop for the .NET platform.

I've used F# at work.

It does have a sort-of REPL, you don't have to put one line functions inside a dummy class, and the async monad and queues are pretty handy.

It doesn't benefit from adding yet another set of collection types to the .NET API (which already has two semi-competing sets) but that is unfortunately beneficial, partly due to the next point.

The balkanisation between the .NET typesystem (class at a time, overloading ok) and the ML typesystem (sequential and no overloading) is a constant source of irritation. How to make a short name alias to the System.Console.WriteLine variadic function?

It's REPL unfortunately doesn't tie into the otherwise impressive VS intellisense and is a pain to attach the debugger to.

It hasn't proper closures (you cannot mutate variables you close over).

It's not a coherent platform, but a mishmash.

Here's F# on OSX: http://blog.mbharrington.org/2010/10/27/fsharp-on-osx/

I love it!