How to drive F# Adoption - Part 1?

[KevinRansom]

F# is great programming language and yet it is under utilized. I would like to understand what you the enthusiast F# developer believes are the top four things we can do to drive adoption: As a developer I believe they are features, if someone has already suggested your top thing, repeat it in your list anyway.
Please keep discussion to a minimum for this exercise. We can discus the results elsewhere, later. I just want to get a feel for everyone people thinks.

[KevinRansom]

My List:

• Support for coreclr
• Much better tooling --- I.e Incorporate Powertools and Compiler Service
• Templates for Web Programming / Azure
• Much improved library / extensions / type provider discovery

[jamessdixon]

UWA (ran into that again this AM - PCL doesn't cut it)
+1 tooling

[rodrigovidal]

• Better Folder support (C# devs love folders)
• Multi-pass compilation. (Most developers are not used to single-pass compilers)
• +1 for Incorporate Powertools and Compiler service
• asp.net 5 support

[eiriktsarpalis]

While C# to F# interop is pretty much flawless, the opposite story has many pain points. For example:

• F# optional parameters awkward to use from C#.
• Lacking an easy way to define F# functions in C#.
• F# extension methods are impossible to use in C#.
• The ever-present implicit dependency on FSharp.Core.

Often when needing to make F# libraries consumable by C# code, I need to define lackluster C# wrappers that are mostly boilerplate. I think that this weakness may have contributed to some extent to the lack of success that F# libraries have had in the .NET ecosystem, which can in turn reinforce attitudes that F# is really just a toy language.

Other than that, +1 tooling/debugger improvements, +10000 CoreCLR support.

[SabotageAndi]

+1 tooling
support or better support for different platforms (coreclr, Univeral Apps, Xamarin)

[lefthandedgoat]

• Marketing and Evangelism from Microsoft (I can't even tell you the number of times people have told me that they have never heard of F#, including MS employees)
• coreclr love
• Slightly better tooling in VS, Resharper support

[jeroldhaas]

• F# on linux has much room for improvement. Problems working with older versions of mono, mainly, since a few distros don't keep mono up to date
• Editor support needs to be on equal ground, with respect to features (Emacs vs Vim vs Code vs VS vs XS...)
• FSI is painfully behind when compared to other REPLs
  • save / restore session like RStudio
  • "workspace" view like RStudio where bindings can be viewed
  • intellisense / colorization
  • font customization / generall look & feel
• Project templates need love
• F# Web projects are very difficult to work with in VS
• Roslyn and F#?

+1 on macros, compiler extensions

⭐ Perhaps the ability to compile to something other than IL? (F#->JS-AST, LLVM, ELF, MinGW)

[7sharp9]

Add more value to the core language:

• Add macros to the language
• Add compiler extensions to the language

[forki]

Tbh with the success of powertools and ionide I would vote to get the IDE
tooling completely out of this repo. These two repos show really good
quality and fast release cycles if something goes wrong.
It's also much easier to contribute since everything is in a build script
and there are no hidden internal product builds.
I'd love to see Microsoft contribute to these projects in the future.

There is still lots and lots to do in this repo and coreclr + .NET native +
Azure are things that would belong here and in other MS repos.

But please don't kill the OSS effort of the other projects by taking
control.
On Dec 16, 2015 20:34, "Andreas Willich" notifications@github.com wrote:

+1 tooling
support or better support for different platforms (coreclr, Univeral Apps,
Xamarin)

—
Reply to this email directly or view it on GitHub
#798 (comment)
.

[ploeh]

Here are my thoughts on how to make F# more attractive to 'mainstream' developers. Oh, dear, here we go:

Make F# a first-class .NET language

You may claim that F# is already a first-class .NET language, but it's not, really. IIRC, when you install Visual Studio 2015, you have to actively select F# as one of the optional languages; if you don't select it, it's not even going to be in Visual Studio.

Furthermore, look at how Microsoft talks about .NET and Roslyn: It's C# here, C# there, and then occasionally C# and Visual Basic.

This tendency is clear with the new ASP.NET stack, as well as with Universal Apps.

Outside of the Visual F# team, it seems like F# isn't really on the radar - not even in the rest of DevDiv, and certainly not in the rest of Microsoft.

The (open source) F# community is doing a great job of tooting the F# horn via other channels, but the .NET community (if such a thing exists) as a whole is still largely taking its guidance from Microsoft.

When there's no templates, no samples, no documentation, in Visual Studio, for most .NET developers it doesn't exist.

What's really been puzzling me for a long time is that Microsoft doesn't realize what a gem they're sitting on.

Programmers migrate towards better languages. When Java stagnated, many migrated to Scala (and Clojure). Programming languages matter. Microsoft as a whole sort of realises this: just look at the scramble towards JavaScript.

F# is a unique language offering, because it's the only(?) 'industrial strength' programming language that offers a Hindley-Milner type system.

• F#: Strongly-typed, Hindley-Milner
• Scala: Strongly-typed, but not H-M (AFAIK)
• Clojure: Dynamically typed
• Erlang: Dynamically typed (I think)

It may not be everyone's cup of tea, but if you want to be 'almost as Functional as Haskell', but can't convince your organisation to take a chance on it, F# is a great choice.

Furthermore, due to the interop with .NET, it's easy to gradually introduce F# into an organisation that already runs .NET.

Better tooling

All that said, better tooling is still needed. As @forki mentions, there's a lot of good to be said about F# Power Tools, but there are also areas where the Visual Studio editor seems too 'primitive' compared to the C# editor.

E.g. it'd feel more modern with

• Code Lens
• Peek Definition

I don't know if these can be built with F# Power Tools, but since it hasn't happened yet, I suspect these are some proprietary Visual Studio UIs that are locked down...

Better web tooling support

Web development is still a thing, and if the web development support is poor (e.g. lack of templates), you lose a lot of adoption right there.

ASP.NET vNext isn't making it easier to get started with web development on F#. While I'm aware of alternatives such as Suave (and perhaps Freya), they aren't going to win C# developers over if it looks like it's impossible to create an F# web project in Visual Studio.

Faster compiler

The F# compiler is, unfortunately, slow.

Whenever I'm back in a C# project, I'm surprised at how fast I can compile a much larger code base.

The slow compilation time hurts many development processes, e.g. Red/Green/Refactor, which should be faster than 10 seconds. In my experience, it's impossible to keep the cycle time under 10 seconds on a moderately-sized F# code base, because compilation alone can take 4-6 seconds.

Oh, and while we're talking about compilers, I'd like to downvote 👎 @rodrigovidal's suggestion for a multi-pass compiler (sorry, nothing personal). The single-pass compiler is F#'s most precious asset.

[gsobocinski]

I have to agree with @lefthandedgoat marketing and evangelism is the key. I'm also interested in Elixir and the way that they are engaging Ruby devs, amongst others, shows us the way F# needs to go.

[sergey-tihon]

• More love from MS on public events (people should know that F# a first-class .NET language)
• Better FSI with intelissense + some other features
• Better tooling (CodeLens & Peek Definition)
• Folder support in fsproj (Multi-pass compilation or super-intuitive compilation order management with single-pass compilation)
• Project.json should allow to plug external dependency manager, so Paket should be first-class .NET dependency manager

👍 For FSharp.Core
👎 For CoreCLR

[dsyme]

Awesome discussion.

Language

• Progress the language incrementally. I won't discuss that here. (That said, extra language features would make only a relatively small marginal difference in adoption compared to other things.)
• As an aside, I will mention the need to get the language/compiler bug count right down in this repo. I personally find it hard to do major new rounds of language work when I still see a bug trail. (Separating tooling bugs from language/compiler bugs would help with that, e.g. by putting the IDE tooling in a separate repo. My personal belief is that bug "weight" grows at O(n * log(n)) rather than linearly given the time to search and organize issues.)

Compiler and build

• Core CLR +1000. Amazing progress here recently and it's so important to be doing this during the phase when we can still get feedback to the CoreCLR design and surface area. Very, very exciting.
• Keep improving F# compiler performance incrementally.
• Keep incrementally enabling and improving F#-to-JavaScript compilation (not in this repo, but through WebSharper, FunScript, Compiler Service). In the long term it will only become more important to support some modicum of this in various scenarios.
• Keep making dependency management simpler and more sound. It was not happy that "Missing Method Exception" should have been so common for so many years with F# - we put a huge amount of work into making the language sound, only to have DLLs and dependency management bite us. I love Paket because it solved this problem most the projects I work on. Roll on Nuget V3 and Paket vNext, and full credit to Steffen for the huge influence he's had here in making the world a better and happier place.
• Move off MSBuild project files. These just don't cut it for the next generation of hipster programmers.

Visual F# Tools:

• The default Visual F# Tools are a really big place to make a large difference for driving adoption of F# . Millions of people use Visual Studio every day for Windows programming. They are all potential F# users. Many have tried F# and seen that the default tooling needs serious work. The Visual F# Power Tools are awesome. Every person giving a talk or demo of F# in Visual Studio should mention them and show them. Always.
• Given the importance of the default tooling for F# adoption, I think we need to consider again integrating the Visual F# Power Tools (VFPT) with Visual F# Tools (VFT). (Tactically, this could either be done in visualfsharp repo, or by making VFPT a complete replacement for VFT, and/or by making a new repo that holds the integrated combination. Microsoft would then ship this combination as the default tooling in Visual Studio. Either a repo managed by Microsoft (like this one) or one co-managed by a highly trusted community member and Microsoft. Quality and performance would need to be prioritised - I'm kind of assuming the absolutely awesome boom in VFPT functionality plateaus a bit)
• Start an initiative for better F# Interactive tooling in Visual Studio. Probably as a sister repo to this one initially, co-run by a Microsoft engineer and with some Microsoft PM oversight, but with a clear path to convergence & integration into VFT.

Upstack frameworks and tools (Web, Cloud, Client, Data, Data Science, Build, Test, ...)

• I'm a huge believer that the biggest area by which to drive more adoption is through better and greater "upstack" frameworks, meaning for web, cloud, client, data, data science, build, test etc.. People flock to languages with frameworks that suit a need and a purpose. F# has come a long way recently (e.g. Suave, MBrace, FsLab, FAKE, FsCheck and many more - sorry not to list your favourite). Supporting and growing a really compelling set of upstack technologies is crucial. Likewise, support in more canonical .NET frameworks is even more crucial too.

[rodrigovidal]

@ploeh Hey Mark, I really like F# single-pass compiler, I do know it's value. But I really think that it's something that harm's adoption.

As far as I undestand, Kevin asked about what could drive adoption, not what I would like F# to be. (That would be lots of language features like typeclasses but it wouldn't drive adoption). F# is the only language I know that has this feature, and it's very annoying when you are a beginner. That's one of the main complaint I have been listening from C# developers over years.

Maybe I'm wrong. :)