Roslyn support for F#

Jun 16 at 3:21 AM
Hi F# team,

I put a message out on Twitter asking what the current thinking is around Roslyn support for F#:
https://twitter.com/MitchDenny/status/477434756003405824

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.

With that in mind - what are the plans?
Jun 16 at 3:46 AM
I think this is extremely important. I'm using F# for web programming today, and I want to be able to continue using F# for web with asp.net vnext.
Coordinator
Jun 16 at 4:46 PM
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.

Does that make sense?

Kevin
Jun 17 at 7:38 AM
Hi Kevin,

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#.
Jun 24 at 3:09 PM
Mitch,

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.
Jul 9 at 9:13 PM
Edited Jul 9 at 9:23 PM
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.

Please advise.
Coordinator
Jul 9 at 10:12 PM
Edited Jul 9 at 10:14 PM
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.
Jul 9 at 11:15 PM
@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.
Jul 10 at 1:55 AM
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.

Thanks for the advice everyone.
Jul 10 at 3:07 AM
@aadams You should check out the following:
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.
Jul 10 at 1:11 PM
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 all the help so far.
Jul 10 at 6:19 PM
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.

We recently converted our iOS app from Objective-C to Xamarin + F#. We are investigating a move from straight JavaScript to WebSharper or FunScript. Doing so should allow us to share even more code and avoid a lot of bugs we currently run into with JavaScript.

@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?
Jul 10 at 7:38 PM
Edited Jul 10 at 7:39 PM
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?).
Jul 10 at 8:13 PM
@aadams, if you are in Houston, please come out to the Houston Functional Programmers meetup Wednesday night. I'll be presenting the materials in the links above and how we use F# at Tachyus. http://www.meetup.com/Houston-Functional-Programmers/events/192430922/
Jul 10 at 8:29 PM
Sounds good, and thanks for the invite. I'll make it a point to come out next Wednesday.
Nov 6 at 5:18 PM
For those following this thread, you can find the current state of F# support in vNext at http://alxandr.me/2014/08/05/vnext-with-a-touch-of-functional/.