You can see from my blog that I have been increasing my adoption of F# and my love of the language is growing. I find the language very conducive to cloud computing. F# at its core seems to be built for distributed computing. If you program with F# in an idiomatic way, you are setting yourself up for success on the cloud, as the cloud is a variably sized distributed system that you are deploying production code to. That is what F# excels at.
As much as I have loved F#, it has not been all roses and sunshine. There have been issues. This article at its core is really an ask from the community to support me in building the case and evangelizing F# in such a way it can be recognized and adopted not only by the community, but by those who make the decisions to expend resources on additional tooling and support. I must iterate that the contents of this article are in no way the opinion of Microsoft, but merely my own observations. From these observations I have developed a strategy and action items that we the F# community must do to achieve these goals.
First, we must step outside of our normal mindset as F# developers and begin looking at the language from the outside perspective. We must also look at some trends.
1. Microsoft and the Visual F# Tools.
Microsoft is currently investing in increasing support for: Linux, Python, PHP, Ruby, and above all its cloud platform Azure. Let’s break this down a little bit. Why is Microsoft investing in these technologies? Supporting these technologies is highly profitable. This is a simple play: drive more revenue and adoption of cloud services amongst existing audiences. Linux, Python, PHP, Ruby are all open source, commonly adopted and taught in schools. They don’t have to be good technologies, they just need to be profitable technologies. I don’t use any of those technologies personally, therefor I cannot speak to their capabilities, but if every student going through a program is receiving exposure to those technologies, it only makes sense to support them.
What does this mean for F#? Well, F# exists in the real world. It may be one of the best technology choices for production code and a favorite in the functional world, in addition to being cross-platform, mobile and free; however, it is not yet adopted as the ubiquitous, mass-movement technology that it could be.
Don’t get me wrong – the Visual F# Tools are profitable for Microsoft – when startups like Tachyus and Jet.com choose F#, Azure and Microsoft benefits. However, we also need to recognize that F# and the Visual F# Tools could be much, much more profitable for Microsoft. If they received more investment, ease of use would increase as would adoption and thus profitability of tools. There is a chicken-and-egg problem here. The Visual F# Tools get used for many things, by many Microsoft customers, but they need to be better to get more people adopting them. This item is thus discussed in my strategy moving forward. Gain popularity of F# while dealing with our Chicken v.s. Egg scenario for the Visual F# Tools.
2. Marketing and Evangelism of F# is often in the incorrect direction.
Most programmers don’t care about functional composition, less lines of code and pretty code. They care about “Can I save the world with this?” and “Can I do it quickly/easily?”. Many of us post “look how few lines it is”. Great, good for you. That is not a reason for me to switch to the F# language after years of experience in another language. That is not a reason for me to add additional tooling for you. Also, somewhat inevitably, our community is tightly knit, which leads to evangelizing and marketing to people who have already adopted F#, which is a waste of energy. They already know it, and love it. This is hard to avoid, but is a reminder that we always have to reach out to audiences, who may not share the same concerns as us.
3. Some of the F# documentation is catering to experts, operates in a vacuum, and uses complex language.
Much of it is good – for example, FSharp.Data is great. But we need more than that, much more. In today’s world of computing there are more integration points not only between components, but languages. Documentation should provide guidance around all aspects. F# is sometimes not the right tool for the job, especially in its current state, therefor documentation to easily deal with this is needed.
4. Business Decision Makers make informed decisions based on hard data and facts.
The community does a great job at informing of their thoughts and feelings and opinions, but that is not the sort of data that is actionable.
I will now break down my strategy for increasing F# adoption in key areas along with examples of what I am doing, followed by asks of the community.
The Strategy Moving Forward in Order
1. Fix Simple Stuff.
Documentation, tooling, Azure Support. Better F# documentation for Azure is the #1 request for the Azure SDK. However, the tooling teams will not spend resources on complex asks. F# must generate enough financial impact to make it worth while since it is competing against other significantly more popular languages with broader audiences. To generate financial impact, it is purely a numbers game. You must have a large enough user base for investment to become compelling. This is difficult. If tooling is terrible (and Azure support is terrible), then how do we move forward? The answer lies in amazing documentation that is simple to use with github samples.
Asks of the community on this one:
a. Contribute to the Visual F# Tools. Just do it. You use F# in Visual Studio, now learn how to improve it. They are open source. Go learn how to help, go be part of the future of the most important tools for this great language.
b. Contribute to the Visual F# Power Tools. Yes, it’s annoying that the core tools are not in a single package. But these are great additive tools and they also need contributors.
c. Help the Visual F# Tools and Visual F# Power Tools to converge. These packages are disparate and it is annoying to install multiple extensions. Preferably get this combination built into Visual Studio itself.
d. Allow click, drag drop in F# projects along with subfolders. This is actually in the Visual F# Power Tools, but is not on by default, so please, please help make this better.
e. Help with documentation for example – integrating with C#. Nearly everyone needs to know this, but we need much, much better information for beginners. Many beginners go to http://fsharp.org for guidance, and that’s one place you can contribute new material. Just do it.
f. Make F# and Azure simpler. For cloud programmers (and that’s where the future is!), help provide full, complete and quality documentation on leveraging C# Azure Libraries with F#, either by wrappers presenting libraries idiomatically or just by quality samples.
f. Push For Microsoft to Open Source Documentation. This could be huge. Right now, documentation is fairly closed off and highly curated. This leads to issues not only in the F# world, but across all technologies. Example, go find a sample on how to write a C# Web Job that is continuously running, not bound to a queue or something. Good luck, its not there. A curated community led documentation process would be phenomenal.
2. Keep Pushing what F# is amazing at.
What we should all do:
a. Show these capabilities. Don’t talk about “functional composition is great” build a project where you leverage it in this manner. “less lines of code to do x”, SHOW IT! 10 lines of code can change how your entire code base operates! Do it in this context. People will adopt a technology where these capabilities are proven with examples. Thus driving the need for better tooling.
b. Use the cloud and Azure to demonstrate these concepts at scale. The issue we have is entry points. Cloud Services, Web Jobs, Event Hubs, many of these products are written with imperative code and therefor difficult to use with F# idiomatically. But demonstrate the concepts here, and piece by piece wrap each entry point with code that allows for use in an idiomatic fashion. And contribute your examples back to github and FSharp.org
3. Track Human-relatable Impact of F#
As I said earlier, we have several facets playing into this. Decision makers respond to hard data. Adoption is driven by things that can be related to. Consider two applications: Marketing App A: Finds all people who like hockey and sends them an email about on sale hockey equipment. Marketing App B: Does A + determines what else they are interested in, cross references from other sources and presents in a more conducive manner to that particular individual. Marketing App B has greater impact than App A. This is human relatable in it speaks to a want for increased revenue. There are loads of applications out there that do simple things, with low impact. Almost every F# project I have run across is high impact. These projects need to be tracked.
Many of these projects are tracked on http://fsharp.org/testimonials, but we need more.
What we should all do:
a. Submit your testimonials! For all F# projects that demonstrate impact, add a testimonial to fsharp.org/testimonials AND/OR send an email do dacrook [AT] Microsoft.com with the following information: Project Name, Project Development HQ, Technologies Used, Project Description, Impact of Project on World, Why F#, contact info.
4. Incognito F# presentations to non F# groups
As an F# community, we tend to stick together. There are F# meetup groups and now even some F# conferences. But what we do is of great interest to other groups. To demonstrate this, I do Web Dev and Cloud Dev camps around the East US. During these camps, I have components that do various things like scrape github, or run complex calculations in real time at scale while leveraging the capabilities of the cloud. I do not present these items as F# content, but rather “Here’s how I solved complex problem A”.
What we should all do:
a. Show F# to other communities. Frame it in the context of solving complex problems. F# just happened to be the best tool for the job. If you are a consulting firm, this should be great for you, because very few know F# as of today and the cloud is the future. What better opportunity is there when you have a language geared for the future and people today don’t know it.
Hopefully this broke down the adoption problem and provided insight into why I personally think F# – while successful – could be much more successful still. If the community can action on these items, F# adoption will increase and tooling will become better. This will make my development life easier and allow me to solve the big problems I want to solve easier and faster without having to worry about integration as much.
I am a full believer that the F# language is perfectly set up to be the language of choice for production cloud development, but it needs to have these few issues resolved, and this is how they will need to be resolved.
Thanks you for reading, and hopefully this was a good read and can help provide insight and direction,