TL;DR We’ve moved the F# GitHub repository from microsoft/visualfsharp to dotnet/fsharp, as specified in the corresponding RFC.

F# has a somewhat strange history in its name and brand. If we roll back the clocks to the year 2015, F# sort of had two identities. One side of this was Visual F#, or “VisualFSharp”; a product within Visual Studio comprised of a compiler and tooling that you could use on Windows. The other side was F#, or “FSharp”; an independent language with a roaring community that built F# tools, a library ecosystem, and multiple packagings of F# independently of Microsoft.

Although this duality about F#’s identity was quite stark, it was also confusing. If you used the term “F#”, what exactly did you mean? Stuff that Microsoft built? Or something else? So, Don Syme (creator of F#) penned a framing in his blog post, An open letter about the terms “F#” and “Visual F#”. This distinction was simple: if you’re using F# from Microsoft (i.e., on Windows via Visual Studio), it’s called Visual F#; otherwise, it’s called F#! Simple, right? As you might have guessed, things got more complicated over the years…

While this split in terminology was arguably needed in 2015, it became more confusing over time. For one, there’s not really anything “Visual” about F# in the tradition of the “Visual” moniker for Visual Studio tools. It never had support for visual designers, and there are no current plans to build designer support for building Windows apps. F# is also not a visual programming language, nor is there any dialect of F# that is a visual programming language (to my knowledge). And with the advent of .NET Core, F# is now officially built and packaged by Microsoft in a way that is orthogonal to Visual Studio and Windows. It has long been a request from the F# community that Microsoft take non-Windows and non-Visual Studio packagings of F# seriously. Many F# users use .NET Core on macOS or Linux, using Ionide with Visual Studio Code, Vim, or Emacs as their primary editor!

Over time, .NET Core has become central to the future of F# and the entire .NET platform. For example, F# 4.5 released with a sizeable feature area (Span<'T> and friends), which is a .NET Core technology. F# is also installed by default in Visual Studio due to being installed as a part of the .NET Core SDK. Much of the F# community has embraced .NET Core, porting existing libraries and creating new ones for consumption on .NET Core. It’s become clear to us that much of the F# community’s center of gravity involves .NET Core (and .NET Standard), including F# targeting JavaScript (via Fable ) and F# targeting Web Assembly (via Bolero) that have emerged independently of Microsoft. This is quite a different world than 2015!

Additionally, .NET has grown beyond the umbrella of Visual Studio and Windows. The .NET Foundation is an independent, 501(c)(6) nonprofit organization that houses many projects; including the C# and VB compilers and tools, the .NET Core runtime and libraries, and many independent open source projects that have no affiliation with Microsoft. I’ve personally noticed an uptick in OSS .NET activity, and the general .NET community’s acceptance of OSS components solving problems differently from Microsoft solutions seems to have also increased. F# has always had an independent nature to it, and a similar characteristic has developed in .NET itself.

As all of this has transpired, a distinction about F# based on the “Visual” moniker and Windows/Visual Studio has made less sense over time. To that end, we’ve taken some steps to help clear things up:

• Branding F# as “an open-source, cross-platform functional programming language for .NET”
• Referring to assets we produce as “F# language”, “F# compiler and core library”, and “F# tools” in Visual Studio release notes, with all community attributions in line
• Tracking the supported F# version in .NET Core downloads independently of Visual Studio

The next step has been to rename the GitHub repository where F# is developed from microsoft/visualfsharp to dotnet/fsharp as-specified in the corresponding RFC. We feel that this aligns well with the current state of affairs.

Cheers, and happy hacking!