Having said that, nearly all of the "core" projects are now being CI tested on mono as well as windows, and the fsharpbindings project provides autocompletion for Vim and Emacs (+ powers the MonoDevelop/Xamarin Studio F# support as well).
I'm having great fun writing F# code in Linux with Vim - now that .fsx (F# script) files have proper #! support you can just write fsx files with full highlighting, error checking and autocompletion in place and then run them with supervisord.
(Edit: although http://fsharp.org/use/linux/ covers the absolute basics pretty well)
Up until recently, packaging was a bit of an issue, but recently the official Mono repositories have started being much more up to date again, and now include recent versions of F# as well: http://www.mono-project.com/download/#download-lin
Getting vim support is still a case of cloning the project from github https://github.com/fsharp/fsharpbinding and running make in the vim directory - Vim 7.4+, make, python and a couple of other vim plugins required.
After that, things can start getting pretty nice. For (my only public) example, https://github.com/mavnn/Advent2014 shows how you can use fsx scripts and paket (a package manager compatible with nuget.org and taking source dependencies from github) to create a nice little project without needing to get into any of the Visual Studio project file nastiness. Of course, if you need to work on an existing project, the Vim bindings know about how to handle that too - but actually editing project files is still a pain.
One word of caution: there's currently a bug in the packaging for rpm: I'd go with Debian/Ubuntu packages at the moment. And as a final option, building from source is slow but has become pretty reliable over the last year or so.
The ecosystem is huge; http://nuget.org hosts the main .net package collection, and it fairly comprehension. Also, to be fair to MS the standard library is pretty "batteries included"; it just doesn't always have what I would consider the nicest APIs.
It does mean that you lose a number of traditional clr advantages such as JITting - and I have to admit that I haven't tried this route myself. Almost all of the clr code I've written has been server side.