But I wouldn't use it with ASP.NET. Learning F# is pretty heady and it would give your average .NET developer fits to learn it. You'd lose an advantage of using the .NET platform then - it's pretty easy to get average developers to be productive in .NET/C#. Forcing developers to learn F# would grind productivity to a halt.
Also, because of the whitespace requirements, F# is lousy in the webforms view engine. (Perhaps a Mako-like templating engine for F# would make sense).
Stick with C# for your web work and your libraries that your web site are using. Life will be easier.
If you really want to delve into F# on the web, these guys did a framework designed to be used with F#: http://www.bistroframework.org/
They also did a .NET port of the django templating engine: http://ndjango.org/
The largest contention point arises when we pass F#-ish types to the ASPX page for rendering. It works, it's just that the C# required at that point can be sort of ugly.
Also, don't forget WebSharper, which provides a way to write all your client-side code (JavaScript) in F#. It handles all sorts of things, including async RPC calls. http://www.intellifactory.com/products/wsp/Home.aspx
Now what I'd really like to see is an F# stand alone webserver - that would operate outside of ASP.NET/IIS. I envision a functional Request/Response pipeline, where you can augment the pipeline using function compositoin. Perhaps this could even handled by a computation expression or workflow. ( For those unfamiliar with F#, this is one of the killer features. See how simple it is to handle Async or parallel processing in F#).
Chris Smith has an interesting example of a Session State workflow in his F# book - I would like to see someone attempt that with a full fledged server.
He had to create a C# web project, as Visual Studio doesn't support that for F#. He had to create a C# LINQ-to-SQL project to generate model classes as there's no support to do so in F#.
This saddens me greatly. Here is a potentially great language in the .Net ecosystem and the support for the most basic of things is missing.
To keep apps interactive, you have to doing a lot on the client side. To keep sanity, you want to use a decent language. WebSharper seems to fix both of those.
The example gets around this by just using LINQ to SQL generated C# classes as the model, but that's a big compromise.
http://amazedsaint.blogspot.com/2010/06/creating-custom-view...
Unrelated, but every time I see an F# article I think of a quote from Juval Lowy I heard on the Dot Net Rocks podcast (I think), which went something like "Yeah, with F# you can just slam your fingers onto random keys and it will be valid code"
(edit:formatting)
There are a lot of subtleties to the syntax that are not easy for someone new to the language to figure out, especially if you are new to the functional family of languages. The error messages are not always helpful. I can see F# will be a great tool for certain problems, and once you are really proficient I can understand making a statement like this.
