Whilst it is easy to say that you have no plans to support it I want to point out that within the next twelve months the ASP.NET team will be rolling out vNext that takes a dependency on the Roslyn compiler. Without F# taking steps to support Roslyn it might
dramatically impact the scenarios in which F# can be used for web programming.

What scenarios do you have in mind? how would you like Roslyn to support F#? Right now the Roslyn team have no plans to allow Roslyn to support the compilation of F# code. In my experience I\It is unlikely that the ASP.NET team will exclusively support
compilers based on Roslyn in their plans, I would imagine they will use Roslyn where it makes sense to them.

I think that as a community it is our Job to ensure that F# is a first class development tool useful for the scenarios that we care about, and that we let other languages and teams focus on the scenarios that they care about. We already have an excellent open
source compiler service at
http://fsharp.github.io/FSharp.Compiler.Service/index.htm.

It would make more sense to me if we focused on getting that one back into the mainline VS project and perhaps work with the MVC team to ensure that we have the APIs they need in order to use F# in similar scenarios to their planned use of Roslyn.

Thanks for getting back so quickly. My main trigger was looking at how the deployment process for ASP.NET vNext is changing and how Roslyn is used at runtime to take all of the ASP.NET source code and the assembly is built in memory. Without Roslyn support
F# would be relegated to being an external dependency library. Now coming back to what you said, maybe being a web programming language isn't a key scenario for F#.

F# is definitely a strong language for web programming. However, I've become increasingly convinced that the ASP.NET model is not a best fit for F#. I would still like to see vNext support made available for F# web programming; I am after all an ASPInsider
and one of the OWIN Management Committe members. I had some early talks with the ASP.NET team, and they assured me it would be possible for the community to provide a way for F# to work with vNext. I need to touch base with them again. Thing is, they have
no plans to support anything other than C#. Writing an adapter will need to be a community effort.

Which brings me to my point about the model not being quite right. We have our own, similar tools. Why not write a better mechanism? vNext adds a lot of weight on a fairly simple idea: late compilation of source files on assembly load. The rest is just framework
bits that, imho, aren't a terrific fit for the kinds of abstractions and programming paradigms F# affords.

Lastly, if you are concerned about library sharing, don't be. vNext is adopting OWIN, and OWIN will be the mechanism through which most of the sharing occurs across projects. I've already started on a few F#-focused libraries in this area:
Dyfrig and
Taliesin. We've also got a working group you are welcome to
join. (We are currently focused on merging a few of our similar projects together.)

My 2 cents,
Ryan

P.S. I think vNext is really exciting. If I let on above that I'm not excited about it, I apologize. I just think we can do better for F# if we think through the approach slightly differently.

I was considering using F# instead of C# for my Web API, but now that F# won't be supported by vNext how can rationally choose F# when I'll be loosing out on new Web API features coming to vNext (like enhanced routing)? They should have chosen to support
F# and C# (not VB) IMO.

Besides, where are all the F# w/ Web API w/ MS SQL Examples?! Can't find a good one that shows n-tiers, code reuse, patterns, best practices, CRUD operations!!

This new situation, in my opinion relegates F# to second class citizen status by MS. MS seems to now be putting their resources elsewhere. It's strange as FP is now more popular than ever.

We are interested in working with community on work items that they consider important. As far as I know the ASP.Net team will not be leaving Managed Languages other than C# out in the cold, I am confident it will be possible to use the next generation
Web API stack from non Roslyn languages such as F#. We will, however, have to wait until they are closer to shipping to work out what that looks like and how we as a community need to respond.

You do highlight a weakness in the F# community documentation, however, that end-end web scenarios are not well documented. Perhaps, if you had some thoughts about what would be needed to make that documentation useful, you could share them either here or at
http://fsharp.org.

@aadams
Here's a link to some talk materials I've recently been giving on using F# with System.Net.Http and the SqlCommandProvider as we do at Tachyus. We are not using much of Web API as most of the plumbing, imho, is noise useful more to a traditional procedural/OO
language like C#. Take a look. I welcome feedback on the ideas. I understand that some people want to just use a framework as built, but I challenge anyone to reconsider how F# can actually improve the situation and not just carry on with the standard platform
frameworks.

What I'm looking for is pure Restful Services with JSON payloads with the option to use OData, mainly for CRUD operations and throw in a few RPS for good measure. I'd like the routing to be easy to set up as it is in Web API 2. And of course authentication
options like OAuth would be nice.

@riles01 I don't really care if it's the Web API framework per say, it could be a pure F# framework and all that implies (e.g., remove the DI & OO stuff).

I'm using CSS/HTML/JavaScript/JQuery and AngularJS on the Client side, and MS SQL for persistence. I've already build a rudimentary C# Web API with DI, Decorators, UoW, Repos, etc. but wanted to take a step back and evaluate if there's another (maybe better)
way. Will be hosting in Azure.

I thought to try my hand at using F# as the "Middle" tier (i.e., tiers between the persistence and Web API layer) instead of C# as I would normally do after researching Functional Programming (FP). FP seems promising, interesting, and compelling there
are reasons to use a FP over OO -- and besides FP is becoming very popular. I preferred F# over something like Haskell do to its (more native) interoperability with C# and MS SQL.

But the gravitational pull at MS seems to be behind C# for the time being and there are little in the way of F# examples for what I'm looking for. This seems so strange as F# seems to be ready made for the Web API scenario, more so than C# from what I've read.
In the end this may stymie my efforts to use F#.

@riles01 I'll watch the video and provide feedback if I think it will help.

The ASP.NET team has expressed they will only be supporting C# due to resource constraints. If you want to use everything they will deliver, your best bet is to stick to C#. If you are willing to leave that behind, you will find F# far more expressive than
the frameworks offered or contribute to the F# community projects to provide a F# alternative. Those are really the only current options, though there's probably a lot of stuff the ASP.NET team delivers that just works or will continue to work in the manner
of a F# library + C# "buddy" project.

Thank you for the advice and links
@riles01. Looks like you've done a lot of work around F# and the MS Web stacks.

I'm just now researching FP in general and F# in particular (I come from a C/C++/C#/Java/OO background); do you have any feedback to give on the overall health of the F# community and MS future support?

Any advice for a full stack web developer (in general MS back-end only) in relation of FP and/or F# and is it something worth putting the time into learning?

Since F# has waned over the last couple of years at MS from what I can tell (please correct me on this if you think otherwise), do you think it makes sense to continue down the FP path in another language, and if so what sort of FP web stack do you recommend
(taking into account that I want to use MS SQL and Azure, and I am using a pure JavaScript/AngularJS front end)?

Thanks for sticking with the conversation,
@aadams. I think F# has a bright future. Contrary to your observation, F# has had an incredible rise since last November. The community has grown, Microsoft allowed contributions to the tools and compiler, and more companies actively recruit F# talent.
Two startups in the US are betting their businesses on F#, including my employer,
Tachyus.

In many ways, I look at the opening up of F# as a key indicator of the bright future for F#. The community is active, passionate, and growing. Compared with the rest of the .NET community, F# is probably the most active in advancing the platform. Microsoft
is doing all the work for the other frameworks. Also, once you break away from OO+imperative programming, much of the work Microsoft is pursuing in their frameworks appears unnecessary. To be fair, I'm very excited about the possibilities coming in ASP.NET
vNext, but the parts that excite me, such as lazily constructing assemblies and new project formats, can be done in F# with the FSharp.Compiler.Service. Also, I continue to find that similar implementations are simpler and quick to build in F# (given time,
of course).

At Tachyus, we are doing a lot of the same things it sounds like you want to do. We host on Azure and use F# for our Web API back end. The presentation and sample app materials are a reduced example of how we use F# for web development. The primary benefit
for us is that we are able to more effectively model flows of data from the SQL Server database, perform analysis and calculations, and then, for lack of better terms, "pipe the results into HTTP." In short, we are able to define data flows that
eventually flow out into HTTP to be consumed by iOS and web front-end apps.

@KevinRansom, I think I've mentioned before that I'm very interested in working with you to build out what's necessary to provide some support for the ASP.NET vNext platform. I think it's worth having a design session to think through how far such support should
go, possibly with other community members. Would you mind setting something up?

Tachyus is interesting ... my last position was as a Business Intelligence Developer at an Oil and Gas Co. here in Houston. I helped them build their internal operations facing system that piped in production and accounting data into a data warehouse for
analysis. I built the ETLs and Analysis services cubes (a MS house) and displayed the results in Excel for the most part. I've worked in some fashion in this type of domain and in the MS stack for years.

When I left I was going to start a company just like Tachyus, because I saw a better way to deliver "Business Intelligence" to a business. No co-location server farms and infrastructure support staff; no need to reinvent the wheel with a clean room
BI system (in some cases of course); reduced developer count; consumption devices should be diverse and available (Native Web/iOS); etc.

In the end another opportunity I could not refuse came my way and now I'm trying to build my start-up based on a different idea (has nothing to do with Oil and Gas). Which in turn has put in a position to be able to do a little more research before I choose
which approach to take ... when I walked through the FP door.

The split between F# and C# is interesting, with F# taking the "full" OS approach. I'm glad to hear about the community, but while doing research I got the impression it was not active or large due to the lack of posts on the topic at hand, but maybe
there is another explanation. Again, F# seems like a natural fit for the Web API "way" of doing web development from my research.

I have been tempted by the prospect of more concise, efficient code that does away with a lot of the boiler plate OO stuff I was writing (Gang of Four). And all the EF code I was building to support my tables was already getting somewhat large.

I'm up to the challenge and willing to put in the time to learn FP if in the end it will makes me more productive than I could have been using C#. But it's also important that I can reach out to the community if I have questions on Web related stuff.

@riles01, thanks for the insights and advice. I'll look over the code examples you provided and provide feedback (here?).

The good thing is that Roslyn doesn't care much about the language - its more of an plugin system.

So what is needed is

a Microsoft.CodeAnalysis.FSharp package, that provides the support for the F# language (syntax tree generation, binders, etc.)

a Microsoft.CodeAnalysis.Workspaces package, that provides support for specific project types in Visual Studio, including Web Projects.

a Microsoft.CodeAnalysis.FSharp.FxCopAnalyzers package, that provides common code style checking rules
in that order...

As for the WebProjects don't support F# issue I am pragmatic. I use F# for the business logic (ie. Models and Controllers), and C# for the fronted part (Infrastructure like Routes, Views). I agree that the web project support issue should be addressed, but
after the compiler was ported to Roslyn, since otherwise the support has to built twice.