I must admit, I'm not desperate enough for new readers to hamstring my own publishing to my existing readers - so summary RSS feed is out for me.
I'd consider delaying RSS publication but that's actually very awkward as it's an Octopress website (i.e. created and pushed as a set of static pages, including things like the rss feed).
Packages generally work fine, although if they rely on native binaries they often require a bit of tweaking to point at the Linux .so rather than the windows .dll. That's uncommon in the .net world though.
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.
The F# community seem to be most active via twitter, Google+ and (slightly bizarrely) StackOverflow chat in my experience. /r/fsharp is pretty small, although I've always found it friendly.
It is mainly Windows, but as stated in a few other answers people are using Mono in production. How long ago did you look around? I have to admit that it's only really become fully practical (in my mind) in the last 6 months or so.
It should be possible to plug the F# binding backend into sublime; it expects to run as a separate process and have buffer states passed back and forth as JSON. I don't know much about sublime plugins, but I believe that they're Python based and should be able to handle that reasonably elegantly.
As in a self executing file? Not the standard deploy story, but is in theory possible on Mono with a combination of F# compiler options to compile in all dependencies, and mono's "ahead of time (AOT)" build.
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.
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.
There are definitely people using F# on Mono in production, but it is the smaller brother still.
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.
Un-functional might be a bit misleading for an ML-based, default immutable language. Impure might be slightly more accurate.
Having seen F# written by C# coders who've just learnt the syntax, and haskell programmers who are having to work in a .net environment, I'd say F# does a fairly good job of supporting both. It does make some trade offs to allow easy interop with the rest of the .net world (it's type system is much less powerful than Haskell, Scala or (especially) Idris) but depending on your environment that can be out weighed by the massive scale of the .net ecosystem, easy interop with your existing .net code and very, very good tooling.
It's not that widely known, but you can remove your child from state education as a parent and teach them yourself. You just have to tell the local authority you're doing so in writing.
You are, in your very definition, stating that it fails for more than a handful of intelligent people ("if you set aside the atypical cases of candidates who are esteemed scholars, scientists and technologists, who are nevertheless fervently religious, of whom we can be sure there are more than a handful"). These 'intelligent people' of whom there are 'more than a handful' will also almost certainly disagree with your definition of intelligence.
I might go out on a limb at this point and suggest that defining religious people as stupid is not particularly helpful, even operating from your own assumptions as stated in your own definition. Some intelligent people might happen to disagree with your assumptions as well, but I'll leave that argument as well outside the normally appreciated scope of HN discussion.
True. Unfortunately there is a length limit on submission titles, and it was the best I managed within the constraints. I don't believe it makes it a less interesting read from a Western viewpoint, though.