Reflecting on F# in 2017

2,817 reads

I’m really excited to take part in this year’s FsAdvent. Thank you, Sergey, for all of the work you do with this and F# Weekly.

Three disclaimers:

I’m not a creative person, especially when it comes to naming things, so I’m stealing Stephen Diehl’s title for this post. Although I work for Microsoft, I’m not writing this post on Microsoft’s behalf. All views things expressed here are my own views. This is a long post split into three sections. I don’t have a TL;DR.

2017 has been a very exciting year for F#.

To begin, F# has grown to be bigger than ever, at least as far as we can measure, through product telemetry, twitter activity, GitHub activity, and F# Software Foundation activity.

Active unique users of F# we can measure are in the tens of thousands.

Measured unique users of Visual Studio Code with Ionide increased by over 50% this year, to become far larger than ever.

this year, to become far larger than ever. Measured unique users of Visual Studio who use F# i ncreased by over 20% since last year to be larger than ever, despite quality issues earlier in the year that we believe have inhibited growth.

since last year to be larger than ever, despite quality issues earlier in the year that we believe have inhibited growth. Much of the measured growth coincides with the release of .NET Core 2.0, which has shown significant interest in the F# community.

Telemetry is a complicated topic, and we do not try to account for existing users who are using F# in environments without telemetry, so it’s never perfect. Actual usage of F# in the world is strictly higher than what we can measure.

But numbers and metrics are limited, because they tell only a small part of the story. I’ll attempt to summarize some of the major things that happened for F# this year.

Wew, that’s a lot. I probably missed some things that matter to people, so please let me know if you feel I should list something.

If there’s a single thing I feel most when looking at the above list, it’s pride. Not just in myself or my immediate colleagues, but in the members of the F# community who have done so many incredible things across such a wide spectrum of the entire F# ecosystem. Every single person involved in the above items should feel proud of themselves and their accomplishments. I’m American, and thus prone to superlatives, but you are all rock stars and I’m humbled to work with you all.

I’d also like to mention a few of the things that matter to me on a more personal level:

I was one honored to be one of the Community Heros announced at OpenFSharp:

I think it’s rare to find a job in my field that is this rewarding. There is a lot of stress involved, and the problems that need solving and issues that need addressing are never simple. But it’s worth it every time.

And now, for something entirely different.

I don’t think I’ve ever clarified, for anyone in the F# community, what my precise role is at Microsoft. My title is currently “Program Manager II”, but that doesn’t really mean much. I’ll start with a list of things I’m not:

Software Engineer. I’m a Program Manager! But I do sometimes write code for the product.

Project manager. Nope nope nope nope nope. I’m terrible at process.

Manager. Nobody works for me.

Program. I’m a human, not a program.

Evangelist. Nope. Although I sometimes do things that count as evangelism.

Salesperson. You really don’t want me selling things to anyone.

Data scientist. Not even close. But I sometimes use querying languages to muck about in the mud of telemetry systems.

Product Manager. This is the closest, but it’s not the same as what other product managers do at other tech companies. I have some KPIs that I track, but I keep them low in number and tend not to focus too much on them. I’m actually quite fed up with the silly focus on marginally useful KPIs our industry has adopted, let alone the incorrect means that so many of them are derived and measured.

Every action I take is to make sure that F# is a pleasure to work with and moving in the correct strategic direction so it will grow and flourish for years to come. That means a few things:

There’s a good chance that for any given product or topic that is related to F# in some way, I have some context. The depth of that context may vary wildly.

I help make a lot strategic and tactical decisions about what Microsoft does for F# with the resources it has.

I spend a significant amount of time interacting with other teams at Microsoft. Sometimes, these interactions are merely giving someone context that they asked for. Other times, it’s a fully-fledged negotiation process, where we come to an understanding about who is responsible for the delivery and maintenance of assets under certain circumstances.

I am responsible for some things that are not directly related to F#. Right now, this includes certain parts of Visual Studio 2017 setup and our organization’s efforts around Azure growth. The most recent, tangible result of this work has been to have F# be installed by default with Visual Studio whenever you install .NET Core.

I am always advocating on behalf of F# developers when I am involved in discussions and decisions regarding .NET, Visual Studio, and Azure. My default position on things is if they would make sense to F# users.

I am always learning more about our codebase, and I always strive to understand the moving parts at a high level so that I can describe them to anyone. The codebase is vast and dense, so there are things I am utterly clueless about. My hope is that by the end of 2018, I can contribute reliably to some of the “deeper” areas there.

When I have the time, I evangelize F#, the tooling that Microsoft delivers for F#, and various F# open source projects. I hope to expand this effort moving forward.

Finally, I am ultimately on the hook for the success of F#, Visual Studio users who use F#, Visual Studio for Mac users who use F#, Visual Studio Code and Ionide users who use F#, and Azure users who use F#. Although much of what I just listed are not my direct responsibility, my review at the end of the year depends on my involvement beyond the Visual F# tools which ship as a part of Visual Studio.

This point is key: my role eclipses just the Visual F# tools which ship in Visual Studio. F# is so much more than just the assets Microsoft delivers in Visual Studio, and limiting my actions to just those would do a disservice to F# users. The holistic picture of the entire “F# experience” is what I care about and try to improve.

And now, for something entirely different.

I’m very excited about what 2018 will bring for F#. So many things in the F# ecosystem that were in flux in 2017 have calmed down and have been set up for success. These are some of my assorted thoughts on the coming year:

I believe that F# will achieve the vision of being the best-tooled functional programming language on the planet, with excellent support in any IDE you like, excellent support in Azure, and the ability to use the tooling you want in the entire ALM experience.

I believe that the F# community, especially through the F# Software Foundation, will continue to grow and become an active home for newcomers to the language.

I believe that Fable will garner even larger interest in the JavaScript community than it has this year.

I believe that F# on the server via .NET Core will be a compelling option for many people and organizations.

I believe that F# will have an even stronger conference presence than 2017.

I believe that the increase in F# OSS activity, .NET Core, and Fable will drive F# to new heights in terms of usage and activity.

I’ll also share some of the things that I personally want to focus on in terms of what my team delivers:

Finalizing Type Providers as .NET Standard 2.0 components.

Delivering F# Interactive support for .NET Core, as a .NET Core application, accessible via fsi on the command line, installed via a .NET CLI global tool.

on the command line, installed via a .NET CLI global tool. Package management via #r “packagename" in F# Interactive, running on .NET Core.

in F# Interactive, running on .NET Core. Completing the .NET Core SDK-based project support in Visual Studio 2017, including multi-targeting and file ordering, templates for Azure Functions and ASP.NET Core, and incorporating relevant templates from the community.

Completing detailed performance analysis of the F# Compiler Service, with engineering work to address the findings.

Continuing the F# 4.1 work towards better error messages.

Working towards shipping a new language version.

New and improved features, such as the ability to Go to Definition on types defined in metadata, or revamped autocompletion.

I view the above as a fairly realistic set of things that you’ll all enjoy over the coming year. I’m quite hopeful that every one of these things will be something to brag about by next Christmas.

2018 is going to be an incredible year for F#. Until then!

Tags